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Chapter 1 

Introduction 


The Ada 9X Language Precision Team (LPT) was formed in 1990 to study portions of the design of 
Ada 9X from a mathematical perspective. The first LPT project studied small parts of the language 
in isolation, formulating fairly simple models to explore the ramifications of the design. The idea 
was to avoid spending time studying the conventional parts of the language (where, we felt, little 
would be gained by the analysis) and to focus on the novel proposals such as the object-oriented 
features, overload resolution, and exception mechanisms. The results of this first project appear in 
two reports [9, 2]. 

The second LPT project had two separate goals. The first, similar in approach to the first 
project, was to study the rules of allowed optimizations. The second goal was rather different. 
Instead of defining many unrelated small models, and studying new features in depth, the plan was 
to formulate a broad model to cover a large part of the language. In this way, we hoped to find 
problems arising from the interactions between different features. 

The level of effort of the project was clearly insufficient to define a complete model of the language, 
and our plan was not to make a complete model. Instead, w T e planned to define the framework for 
such a model, and to fill in the details of the framework only in certain areas. Furthermore, the 
framework was not intended to be complete; we did not expect to be able to describe concurrency or 
distributed programming. We did, however, hope for the framework to cover most of the sequential 
features. 

Our expectation was not that the resulting incomplete model would necessarily be useful to 
anyone (although we hope that it could be extended to form the basis for analysis tools). Instead, 
we expected that the activity of making this model would allow us to influence the design of Ada 
9X by identifying problems with specific language features or with the interactions between different 
features, or by suggesting improvements in the ways that parts of the language are described. As 
the design of Ada 9X was nearing completion when our project began, it was important to move 
as quickly as possible. So, the model is quite sketchy in areas. Moreover, the formal definition 
presented in this report omits several partial models that we built in the course of the project, as 
we did not have the time to integrate them with the overall framework. None the less, these models 
have played a useful role in helping us to understand and comment on various language features, 
and to influence (however slightly) the design of Ada 9X. 

This report is organized as follows. The method used for defining the model is described in 
Chapter 2. A discussion of the model also appears there. The model itself appears in two parts. The 
“domains” (sets describing the values assumed by different entities in the language) are described in 
Chapter 3. The “judgements” describing possible executions of a program are described in Chapter 4. 
Our study of the optimization freedoms described in [11.6] does not fit into the main framework; it 
is described separately in Chapter 5. Conclusions are drawn in Chapter 6. 

Two appendices give some additional information. Appendix A lists the official language com- 
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ments that were submitted by the LPT; most of these apply to Version 4.0 of the Draft Standard [3], 
and several have resulted in changes that appear in Version 5.0 [4], Appendix B describes the inter- 
mediate syntax that results from overload resolution (and other static checks). 

References to the Ada 83 Reference Manual [10] appear in the form [RM-83 c.s(p)], where c 
is the chapter number, s the section number, and p the paragraph number. References to version 
5.0 of the Annotated Draft Standard for Ada 9X [4] appear in the form [c.s(p)]; this standard as a 
whole is often referred to as “the Reference Manual”. 
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Chapter 2 

Method of Description 


The “broad semantic framework” is defined using Natural Semantics [5]. The general idea of natural 
semantics is to define semantics as one or more relations between syntactic phrases and semantic 
values. These relations are defined using axioms and rules of inference. As a trivial example, a 
simple language of arithmetic expressions can be defined by the grammar 

expression ::= numeral I <expression> "plus ' 1 <expression> 

We can define the semantics of these expressions using a relation (between expressions and numbers) 
of “evaluates to”, which we will write as expression => value , and a relation (between numerals and 
numbers) of “denotes”, which we will write as numeral — > value. 

Two rules suffice to define the semantics of expressions (although additional rules not shown here 
are needed to define the “denotes” relation). The first covers the base case of numerals: 

n — ► v 

[ n £ numeral ] 

n => v 


The second gives the semantics of sums: 

el=>iT e2 v2 

el plus e2 => vl 4- v2 

The method is easily able to handle nondeterminism, where a phrase can have many possible 
results. If we extend the expression grammar above to include ranges, with the meaning that any 
number in the range is allowed, we have the grammar 

expression : := numeral 

I <expression> "plus" <expression> 

I <expression> <expression> 

Only one additional semantic rule is needed: 


el => vl e2 => v2 

e 1 . . c2 => v 


[ vl < v < v2 ] 


Using these rules, we can deduce 


(0 . . 2) plus (10 . . 20) => x 
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for any x between 10 and 22 inclusive. 

In practical applications of Natural Semantics, the judgements used are often more complex than 
in this simple example. Usually, there is a certain amount of contextual information (such as the 
definitions of functions or procedures); this is represented by an environment. Often a store is used 
to record the values of variables. Furthermore, the evaluation of a phrase may have an effect on the 
environment or store. So the judgements often have many components, and there are a number of 
auxiliary domains of semantic values. We write most judgements in a standardized form 

S, E b P ( p ^ v y . . . , 

where 5 is a store, E is an environment, p is a phrase, the subscript pt gives the kind of phrase 
(e.g., whether p is a declaration, statement, expression, or name), v is a possible result of executing 
(or evaluating or elaborating) p, and the “. . .” are any other results that the execution may have. 
Usually, there is a final state that reflects any side-effects that the execution may have had. 

We describe the domains of semantic values using the Z notation [8], which furnishes a standard 
toolkit of notations for sets, functions, relations, and “freely constructed sets. 

The Natural Semantics definitions have been written in a machine-readable form in Prolog. 
Judgements are represented directly as Prolog predicates, and semantic rules as Prolog rules. There 
is a slight difficulty in transcribing uses of functions, but a simple translation to relations is possible. 
The Prolog representation has two main advantages. Firstly, we were able to apply a type-checking 
package developed by Reddy and Lakshman [7] to the definition; this found a number of simple errors 
in the rules. Secondly, we are able to run the Prolog and determine what outcomes are predicted 
by the semantic definition. This allows the semantics definition to be tested on small examples. 

Several aspects of Ada 9X are tricky to define properly. In the remainder of this chapter, some of 
the awkward parts of the language and some of the more intricate aspects of the Natural Semantics 
definition will be explained. Not everything described below has been implemented in the Natural 
Semantics; some of the discussion describes our plan for dealing with a feature even though we did 
not have time to include that feature in the semantics definitions. 


2.1 External Effects and Nonterminating Programs 


Ultimately, the meaning of an Ada program is defined in terms of its sequence of external effects , 
as described in [1.1. 3(8)]. We can readily define several types of external effects, such as operations 
on files using the standard I/O packages, propagation of an exception, or return from the main 
program. Other effects are not covered. 

An outside observer can see these external efFects during the execution of a program, and does 
not need to wait until (and if) the program terminates. Therefore, we use a small trick to allow 
the semantics to assert that a certain sequence of external effects can be viewed whether or not the 
program terminates. We use a special incomplete condition that is treated like an exception that 
cannot be handled. For any operation having an external effect, one possible result is to “raise” this 
condition. The semantic definition then propagates this condition out of the main call. Thus, we 
are able to infer judgements of the form 


Library h program— name => e, 

where e is a sequence of external effects, for every sequence e that might be observed during a run 
of the program. 


2.2 Semantic Simplifications 

Some language features appear to be very difficult to incorporate into this model. For these features, 
we have introduced a notion of an unpredicted result. When our definition allows the deduction that 
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unpredicted is a possible result of an execution, it means that the particular program includes a 
language feature, or encounters a situation, that we decided not to account for in our model. This 
is similar to erroneous executions, where the language standard does not predict the results of a 
program. 

For example, Section [11.6] of the Ada 9X Reference Manuals allows implementations to produce 
results at variance with the language rules described elsewhere in the manual (in situations where 
a language-defined check would fail if those rules were followed). The freedoms allowed by Section 
[11.6] appear to be very difficult to incorporate into the model defined here. Therefore, we have kept 
the model simple by treating the failure of a language-defined check as an unpredicted execution. 

There are some rules new to Ada 9X that constrain the result of an execution that Ada 83 
classes as erroneous. These bounded error situations can be difficult to model. For example, reading 
the value of an uninitialized scalar variable is erroneous in Ada 83. In Ada 9X, it is a bounded 
error, which can result in an exception or an implementation-defined result. Version 4.0 of the 
proposed Standard introduced the concept of invalid values to describe these results. Unfortunately, 
the introduction of invalid values complicates the semantics of the language considerably, as it 
is necessary to provide rulesTor computing with these values. The draft standard does not always 
provide the complete details of these rules. For example, what is the result of a comparison involving 
invalid values? Are the ordering operators transitive, even when applied to invalid values? We 
decided to keep our model simple, and to avoid these questions, by refusing to predict the outcome 
of a program that reads an uninitialized scalar variable. Version 5.0 of the Standard has changed the 
description of this situation, but once again the exact rules are vague. Therefore, we are continuing 
to use the simple model that refuses to predict the outcome of a program in these situations. 


2.3 Static Checks and Overload Resolution 

It is conventional to process Ada in two (or more) steps; the first step checking syntax, applying all 
of the “legality” checks, and resolving any overloading. We planned to define the semantic model in 
a similar way, with two distinct definitions. The first static semantics takes Ada source text, and 
produces a program in intermediate syntax. The intermediate syntax differs from Ada source text 
in several significant ways: 

• Intermediate syntax is in the form of a tree, rather than a linear string of characters. Therefore 
intermediate syntax does not need to be parsed. 

• Overloading has been resolved. Identifiers, characters, and operator names have been replaced 
by intermediate identifiers (in the set Id) in such a way that no two distinct declarations declare 
the same intermediate identifier. Any use of an identifier, character literal, or operator name 
has been replaced by a use of the appropriate element of Id. (Some names using selection, e.g., 
package components, are also replaced by intermediate identifiers.) 

• Many of the notational conveniences of Ada have been eliminated. For example, infix operators 
are replaced by function calls. 

• Generics are eliminated. Generic instantiations are expanded to a sequence of declarations. 

• Some additional information is included. For example, a completing declaration is explicitly 
marked as such. 

The intermediate syntax is described in Appendix B. 

We have not formally defined the static analysis, although we believe that a Natural Semantics 
formulation of the static rules is possible. 
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2.4 Environments, Entities, and Stores 

The Natural Semantics definition is faithful to the Reference Manual in its treatment of entities. 
We use several different sorts of “entity locations”, which serve as unique names or references for 
entities. When a declaration is elaborated, new names are generated for any of the entities that 
need to be “created”, and the environment is updated to reflect the association of the declared Id 
with a view of one of these entities. The store is a collection of mappings indexed by these different 
entity locations, which associates a value or meaning with each entity. 

This indirect representation, using references to entity locations rather than the meanings of 
entities, makes it fairly easy to handle situations where an entity has a declaration that is separate 
from its definition. Between the declaration and definition, any references to the entity cannot make 
use of the definition (because it is not yet known). The location associated with the entity is known, 
and can be used. 


2.5 Ordering 

The Ada Standard gives implementations considerable freedom to select the order in which actions 
are performed. For example, in evaluating a sum, either the left or the right operand might be 
evaluated first. It is easy to write a program that gives different results depending on which order 
is chosen. 

In order to write a concise description of the possible effects of the evaluation of constructs 
allowing a choice of orders, we define a set of actions , and several ways of combining actions. One 
combination, written by enclosing the actions in braces, allows the actions to be carried out in an 
arbitrary order; another, written by enclosing the actions in square brackets, requires the actions to 
be carried out in strict sequential order. 

Actions are similar to judgements, except that the states do not appear explicitly. When actions 
are executed in some order, suitable states are added and the corresponding judgement is used. We 
write the actions in a notation that makes obvious the judgement for the corresponding execution. 
For example, corresponding to the judgement S \ , E b 5fm Stm =$- S 2 is an action written as f E b^ m 
Stm =>'; corresponding to the judgement S\,E \~ exp Exp => V , S 2 is an action written as ' E \~ exp 
Exp => V' . 

We also use states, which are combinations of stores and control flow information (for example, 
whether an exception has been raised, whether a return command has been executed, whether 
execution is normal.) The rules defining the execution of a combined action check the control flow 
information to skip some actions if that is appropriate. For example, in executing “a followed by 
b”, if the execution of “a” propagates an exception, the action “b” is not executed. 

One advantage to this approach is that the actions themselves look simpler than the correspond- 
ing judgements, because the flow of control through them is described by the way they are combined. 
For example, in defining the possible results of a sum using explicit ordering, we would need several 
judgements, including 

s , E h eX p el => v 1 , s 1 
si, E \~exp e2 =>> v2, s2 

s, E h exp el-he2^vl-b v2 , s2 

and 

s, E h exp c2 v2, si 
sl,E\~ exp e 1 v 1 , s 2 

s, E b exp el + e2 => vl + v2, s2 
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and others to account for exceptions. Instead, using actions, we can write 


5! h 


f 9 E h exp 
\ f E\- exp 


el => vY \ 
e2 => v2' J 


*^2 


Si, E h exp el + e2 => vl 4- i>2, S 2 


which accounts for the different possible orders of evaluation and for the propagation of an exception 
from one of those evaluations. (We still need something extra to account for an overflow in the 
addition.) 


2.6 Types 

It is awkward to define a domain of “type values” that describe types, because the exact character- 
istics of a type can change through its scope. For example, a type may be limited in some parts 
of its scope, and nonlimited in other parts (such as the body of a package defining the type of a 
component); a type can be private in some places and not in others. Furthermore, an incompletely 
defined type can be used in various ways (such as a record component or designated type of an 
access type); the characteristics of the using type can change after the incompletely defined type’s 
full definition. 

In order to simplify the treatment of these situations, types are described by descriptors that 
refer to other types by their locations (see Section 2.4), rather than by their descriptors. This has 
the disadvantage that descriptors are not meaningful in isolation, but only with respect to the store 
that associates descriptors with type locations. However, it has several advantages: 

• it gives a simple characterization of when types are the same; each type location represents a 
distinct type; 

• when the characteristics of a type of a component change, that change can be reflected in just 
one descriptor; and 

• circularities in type descriptors are easily handled (without needing any tricky domains allowing 
for infinite data structures). 

An example illustrating these advantages is 
type A; 

type B is access A; 
type A is access B; 

2.7 Values 

We expected it to be easy to describe the domain of values that objects might assume. It was 
surprising that this was not so. As mentioned above, the addition of invalid values to scalar types 
adds several complications, as the nature of such values is not completely specified. The latest 
version (5.0) of the proposed Standard no longer uses the term “invalid value”; instead, a variable 
may have an “invalid representation” [13.9.1]. 

We also argued whether “abnormal” values would be needed in order to model the concept of 
abnormal objects. We were able to avoid this, since the circumstances that can lead to abnormal 
objects are being treated as unpredictable executions. 

There are a few situations where it is difficult to determine the set of values associated with a 
type. For example, given the declaration 
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subtype Void is Integer range 1 . . 0; — an empty range 
type R is record 
v: Void 
end R; 

There are no values of subtype Void. However, there are values of type R. For example, a variable 
of type R can be declared, and it is not an error to “read” the value of such a variable, or to assign 
this value to a second variable of type R. 

The problems with this type are related to those for uninitialized scalar variables, and we adopt a 
simple approach to solve them. We use a special indicator to denote an uninitialized scalar value. A 
scalar subcomponent of an object can have this value. If this “uninitialized” value is read, execution 
is unpredicted. 

The set of values of an enumeration type is not obvious. Given the declarations 

type E is (red, green) ; 

for E use (red => 1; green => 100); 

version 4.0 of the Draft Standard suggested that there were two “valid values” of type E, and (at 
least) 98 “invalid values” between them. The number of elements in an array indexed by E, then, is 
open to question. Are there elements corresponding to the invalid members of the base range? 

Types declared with per-object constraints do not have obvious sets of values (since the constraint 
applied to a subcomponent might depend on the specific object of the type). Our model simply does 
not cover the kinds of per-object constraints that lead to this difficulty. 

Our model for values uses integers to represent discrete values (even if the value is of an enu- 
meration type). This means that the values of different types are not necessarily different. It would 
certainly be possible to mark values in such a way that no value belongs to more than one type, 
but there seems to be no benefit to doing so. An Ada program cannot directly compare values of 
different types, so there is no way for this detail to influence the outcome of a program. 


2.8 Objects 

It is normal in semantic definitions to use location semantics for variables, but different approaches 
can be used in accounting for structured (composite) variables and their components. 

The approach that seems most convenient for us is to associate locations with entire variables 
(that is, variables that are not subcomponents of other variables). Every object is characterized by 
its location and a selector indicating which component of the entire variable it is. 


2.8.1 Actual Subtypes 

The actual subtype of an object is sometimes different from the nominal subtype in its declaration. 
This is an issue for assignments [5.2(H)] and formal parameters of mode in out or out that are 
passed by copy [6.4.1(17)]. So it is important only for variables. 

The actual subtype of a variable differs from its nominal subtype in the following circumstances: 

• the object is a declared object, and is constant, aliased, or has an indefinite nominal subtype 
[3.3. 1(9)]. 

• the object is a formal parameter. [6.4.1(16)] states 

A formal parameter of mode in out or out with discriminants is constrained if either 
its nominal subtype or the actual parameter is constrained. 

[6.4.1(12-15) gives additional rules for out parameters. 
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• Mio object is a generic formal object of mode in out. [12. 4(8)] states that the nominal subtype 
is taken from the declaration of the formal, while the actual subtype is taken from the actual. 

• the object is declared by an allocator, and the designated type of the result subtype of the 
allocator is indefinite or has discriminants ([3.3(23) and [3.10(9)]). 

• the object is a view of another object, and the subtype of the view is indefinite [ 3 . 3 ( 23 )]. 

I his leads to the question of how the actual subtype of an object is determined, and where, 
il needed, the actual subtype information is stored. There are two reasonable choices: the actual 
subtype might be associated with the object, or with each view of the object. However, two views 
of fin object not'd not have the same type. Obviously, in such a case the actual subtypes must be 
different. Moreover, in a procedure call, the actual subtype of the view denoted by the formal can 
be different from the actual subtype of the actual parameter, even when the views have the same 
type, tor example, the actual might be of an unconstrained discriminated type and the formal 
constrained. I here fore, we have decided to store the actual subtype as part of every view of an 
object. 

2.8.2 Initialization 

I lie calculation of the implicit initial value for an object is difficult to describe, as there is consid- 
< (able freedom in the order of evaluation of default expressions used to initialize subcomponents. 
It is particularly awkward for subcomponents with discriminants; discriminants must be evaluated 
belorr any subcomponent that depends on them, but other subcomponents may have their initial 
values evaluated before then. So, given the declarations 

type T(a: D := eO, b: D := el) is record 
u: Integer := e2; 
v: U(a) := e3; 
w: U(b) := e4; 
x: S(a,b) := e5; 
end record; 

y: T; 

\\e must evaluate eO before e3 and e5, and el before e4 and e5. The order of evaluation is ot herwise 
unrestricted (unless references to a or b occur in e2, e3, or e4.) 

In oidei to accommodate this flexibility, we use a variation on t he u in some order' rules described 
in Section 2.*). We add an additional datum to (In' loft and right of the turnstile; this datum records 
\vlii(h discriminants have had their initializing expressions evaluated (and what, the resulting value 
i -s )’ ^ individual actions record t heir prerequisites (that is, which discriminants must be evaluated 
before the action can he executed). 

In the record of evaluated discriminants, wo cannot simply use the name of the discriminant, 
as two subcomponents might have the same type, and thus have discriminants of the same name. 
Instead, for each discriminant subcomponent, to be evaluated we generate a unique ident ifier. A u dis- 
(liminant environment , associating discriminant identifiers with discriminant names, is therefore 
also used in the judgements for initializat ion. 

Anolhei difficulty in describing the init ialization of objects concerns pcr-objcct constraints. Ada 9X 
allows the name ol a type to be used in its own definition, in which case it stands for the “current 
i iinI aut e ol the type. I bus, a constraint, on a component can refer to the containing object. Do 
M l ibing I bis formally can be difficult: the object might not. exist until its subtype can be determined 
(whuh involves elaborating per-object constraints), yet. the elaboration of a per-object constraint 
may refer to the object.. We decided not to consider per-object constraints t hat refer to the “current 
instance" (but we allow them to refer to discriminants). 
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2.9 Aliasing 

Some rules concerning aliasing look difficult to model. [6.2(12)] states 

If one name denotes a part of a formal parameter and a second name denotes a part 
of a distinct formal parameter or an object that is not a formal parameter, then e 
two names are considered distinct access paths. If an object is of a type for which the 
parameter passing mechanism is not specified, then it is a bounded error to assign to the 
object via one access path, and then read the value of the object via a distinct access path 
while the first access path still exists. The possible consequences are that Program_brror 
is raised, or the newly assigned value is read, or some old value of the object is read. 

If we are to allow for accurate predictions of the effects of procedure calls (or to refuse to predict 
the outcome of calls that might involve aliasing), we need to be able to recognize, at a minimum, 
when the above rule might apply. It is not enough just to say that parameters of certain types y 
be passed by copy or by reference at the whim of an implementation, because the above paragrap 
allows for results that might not be produced under either of the two passing mechanisms. We mig i 
refuse to predict the result of any call with aliasing, but that can be hard to recognize if access valu 
are used. Unfortunately, the notion of “access paths” is not well defined by the Reference Manual, 

and the precise meaning of the aliasing rule is unclear. , • 

We have submitted several official comments on the aliasing rules, and had some discussions 
with the Mapping Team on possible interpretations of these rules. One model that may work can 
be sketched ^follows: we would define a function access. path on names which gives an element 
of optional Id. This “access path” gives the Id associated with the declaration of some variable 
denoting the object denoted by the name. This might be the declaration that crea ed the object or 
might b & e the name of a formal parameter. If the object was dynamically created, the access path 

null. . 

In most cases, the definition of access-path is simple, e.g., 

access.path(Id) = some(Id) if Id is not declared by a renaming declaration 
access .path ( JVam . Id) = access. path(Naw) 
access.path{Nam{exp , ...)) = access.path(Nam) 
access-path(N am. all = none 

For Ids declared by renaming declarations, we would want to use the access path of the renamed 

^ In order to state the rule of 6.2(12), we would associate a “last update path” with every object 
(including subobjects). Whenever an object is updated by an assignment, the access path of the 
name used in the assignment statement is recorded in the object (and every subobject and contain g 
object). In addition, formal parameter objects are updated in a call with the formal parameter Id 
as the last update path, and after a call, any in out or out parameter objects are updated by 
the access paths of the corresponding actual parameter names. It would be a bounded error to 
evaluate a name denoting all or part of a formal parameter for wh.ch the parameter p^ 
unspecified if the access path differs from the last update path of the object it denotes^ Sunil y, 
it would be’ a bounded error to evaluate a name if the last update path of the object it denotes is a 
formal parameter for which the parameter passing mode is not specified. 

These rules account for most of the situations described by 6.2(12), but probably need refinemen 
to deal properly with access values created by Access attributes. 
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Chapter 3 

Semantic Domains 


In this chapter, we define the domains of values used in the semantics. These sets describe the values 
assumed by the various entities of Ada 9X. 

These definitions have been used as the basis for the Prolog representation of the Natural Se- 
mantics definitions presented in Chapter 4. However, some of the definitions defined here have not 
yet been incorporated into the Natural Semantics definition, and some small inconsistencies between 
the two definitions have not yet been eliminated. 


3.1 Basic Notations 

In this section, we define some basic notions that will be used in the model. 

An association provides a finite function with an enumeration of its domain. It is convenient to 
represent such a function by enumerating (domain, range) pairs; the finite function is then the range 
of the sequence. 

X A Y == { s : seq X x Y | ran s E X -++ Y A # ran s — #s } 

Functions adorn and aran give the domain and range of an association. Function _ _ is used to 
apply an association to an argument (as though it were a finite function). 


r [A', Y) = ■ = ■■■■■■ 

adorn (X A Y) -+ PX 
aran _ : (X A Y) — P Y 
(X A y) x A -♦+ 7 

V a : X A y • adorn a = dom(ran a) 

V a : X A Y • aran a — ran(ran a) 
(A, x) G dom_ • _ <=> x E adorn A 

x E adorn A => A ■ x = (ran a) x 


We sometimes use optional values: 
optional X ::= none \ some((X)) 

Function maximal returns the set of maximal values of an arbitrary relation, where a maximal 
value of the relation R : X <-► X is defined as an element z of X such that no y ^ z satisfies zRy. 
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f=[X) = = 

maximal : (X <-*■ X) — > P X 


maximal(R) = X \ dom (R \ id X) 


Function restrict restricts both the domain and the range of a relation to some given set. 

|=W = = == 

restrict : (P X x (X <-+ X)) (X X) 


restrict(S i R) = (S x S) fl R 


Equivalently, 

restrict{S , R) = (S < R) > S 

3.2 Entities and the Environment 

After overload resolution, every occurrence of an identifier in an Ada program can be replaced by 
an 7d, so that each Id has at most one declaration in the program. 

The elaboration of a declaration creates an entity, and the Id of the declaration then denotes a 
view of this entity. A declaration might be elaborated many times (e.g., if it appears in a subprogram 
body), denoting a different entity each time. 

Environment —— Id ■+*> View 

A view identifies an entity and provides some characteristics that affect the use of the entity. 
For example, there can be several views of the same subprogram, each having different parameter 
names and default expressions. Views refer to entities by using locations of various types. 

[ Type-location , Subtyp e-location , Object-location , Subprogram^location) 

There are no views associated with packages or generic declarations. Packages are significant 
in their provision of information hiding and modularization, but those aspects concern the static 
semantics, not the dynamic semantics. Generic declarations are expanded by the static semantics, 
so that only ordinary (non-generic) declarations appear in the intermediate syntax. 

Exceptions are unusual entities. No matter how often an exception declaration is elaborated, the 
same exception is denoted. This exception is represented by an Exception-Id that is determined 
by the static semantics. (The Exception— Id could be chosen to be the Id of the declaration, for 
example). 

View object— view (^Object— location x Subtype}) 

I subtype -view {{Subtype-location}) 

| subprogram— view {{Subprogram— location x Profile)) 

| exception {{ Exception _/ d)) 

| constant {{ Value)) 

Most kinds of entity are held in a store . Assigning a location to refer to the entity, and placing 
an entity at that location in the store, corresponds to what the Reference Manual calls “creating” 
the entity. This activity happens when a declaration is elaborated. 

Several kinds of entities are used in the semantics definition: 

• objects, which have values; 
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• subtypes, with their associated type, constraint, and attributes; 

• types, with descriptors and optional parents; 

• subprograms, with formals and bodies; and 

• operations (representing the “predefined operations” of the Reference Manual). 

Store 

types : Type-location -h- Type 

subtypes : Subtype-location -++ Subtype 

objects : Object^locaiion -++ Value 

subprograms : Subprogram— location -++ SubprogramOrOp 


SubprogramOrOp subprogram ((Environment x (seq Id) x Del x Stm)) 

| operation {{. . .)) 

The different sorts of entities are described in the following sections. 

Evaluation is defined in terms of a state, which (usually) includes a store, as well as certain 
control information. States are defined below in Section 3.6. Function the— store , giving the store 
associated with a state, is used in some of the definitions below. 


3.3 Thunks 

In several situations it is necessary to record an expression together with the environment in which it 
appears, so that the expression can be evaluated in some other context. The environment is retained 
so that any Ids appearing in the expression have their correct denotation. We call this combination 
of an expression and an environment a thunk. 

Thunk == Exp x Environment 

Thunks appear in record type descriptors (where they describe the initializing values of any 
explicitly initialized components), and in parameter lists (where they describe any default values for 
parameters). 

3.4 Values 

There are several kinds of values of interest: 

• discrete values (represented by integers) 

• real values (represented by rationals) 

• access values (represented by views of objects or of subprograms) 

• record values (represented by partial functions) 

• array values (represented by partial functions) 

It is possible to use a model where the values of each type are distinct; however, the benefit of 
doing so is not completely clear. The rules of the language do not allow for comparisons of values 
of different types, so there is no way of telling whether these sets are disjoint. 
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3.4.1 Ranges 

Ranges have two bounds, and determine a set of values of a scalar type. 

Range discrete-range ((2 x 1)) \ real -range ((Rational x Rational)) 

Discrete-range == ran discrete -range 
Real-range == ran real-range 

(The definition of the bounds functions contains a forward reference to functions discrete -value 
and real— value , defined in Section 3.4.5.) 

low— bound , high— bound : Range — ► Value 

low-bound(discrete-range(l, h)) = dis Crete -value(l) 
high-bound(discrete-range(l, h)) = discrete-value(h) 

low-bound(real-range(l } h)) = real-value(l) 
high-bound(real-range(l , h)) = real-value(h) 

make-range : Value x Value -++ Range 

make-range(di$crete-value(v) , discrete-value^')) = discrete -range(v , v ) 
make-range(real-value(v) , rea/_ua/ue(V)) = rea/_ran( 7 e(t>, v ) 

_ belongs-to _ : Value <-+ 
ua/ties_o/_ran< 7 e : Range — ► P Va/ue 
_ ts—irac/tided-jn - : Range 

v Ae/on^s-^o KovG t;a/wes_o/^ran^e(/i!) 

va/ue 5 _o/_ran^e(discrete_ran^e(/, A-)) = discreJe_ua/ue(]/ . . A|) 
va/«es-.o/_rfln^e(rea/_rfln^e(/, A.)) = real— value(\l . . A[) 

is.inctodedLtn R' <=> vafoe$_o/_ran 0 e(Ji) C va/izes_a/_ran^e(i?') 

3.4.2 Index Ranges 

Arrays are indexed by sequences of discrete values. Index ranges are determined by a sequence of 
discrete ranges. 

Array— bounds == sec\i(Discrete— range) 

Each sequence of bounds determines a set of indices: 

indices : Array-bounds — ► P(seq 1 Value) 

V B : Array— bounds • mdices(B) = { s € seqj Value | 

# 5 =P AVnG dom s • s(n) belongs-to B(i) } 

3.4.3 Tags 

We use a set of tags. The precise nature of this set is immaterial. 

[Tag] 
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3.4.4 Bindings 

Bindings are simply partial mappings from Ids to values. Most often these Ids are the names of 
record fields or discriminants. 

Binding —— Id -k Value 

3.4.5 Values 

Although it seems redundant, we include the bounds as part of an array value. This is because two 
arrays with no components (thus, with the same mapping function) can have different bounds. 

Record values are furnished with optional tags, discriminants, and other components. This allows 
the descriptions of the various language rules concerning tagged records, discriminated records, and 
normal records to be combined. 

A special value, uninitialized-value, is used for uninitialized scalar objects. This is used to detect 
when such an object is read (in which case the result of the execution is unpredtcted). 

Value ::= uninitialized -value 
| discrete-value (( Z)) 

| real-value ((Float)} 

| access -value {{optional View x optional SubprogramLabel)) 

| record-value {{(optional Tag ) x Binding x Binding)) 

| array -value (({ B : Array-bounds , v : (seq Value) -+► Value | domv = indices(B) })) 
We can define various sets of values referred to in the language rules: 

Discrete-value == ran discrete -value 

Real-value == ran real-value 

Access-value ran access-value 

Scalar-value == Discrete-values U Real-values 

Elementary— value == Scalar— values U Access— values 

Composite— value == ran record— value U ran array— value 


3.5 Types and Subtypes 

Every type has an associated type descriptor giving the characteristics of the type (and possibly 
referring to other types via their type locations). 

The descriptors are defined here, but described in the sections that follow. 

Type-Descriptor enumeration -dsc{^ Ni)) 

| signed -integer -dsc (11 x Z x Z x Z)) 

| modular-integer-dsc ((Ni)) 

| universal -integer -dsc 111 x Z)} 

| float-dsc{{ Ni x Rational x Rational x Float -Implementation)} 

| ... (something for fixed-point types) 

| array -dsc(((seq 1 Subtype) x Subtype)) 

| i'ecord-dsc(((optional Tag) x Discriminant-descriptor x Component -list-descriptor)} 
| class-dsc((Type-location)) 

| access-dsc((Subtype-location x Access-Mode)) 
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A type is then a combination of an optional parent (in case the type was derived) plus a descrip- 


tor. 


Type ::= ( optional Type-location) x Type— Descriptor 

For each kind of type in Ada 9X, we define a type descriptor. Additionally, for each descriptor 
we define the set of values of the type: 

| descriptor-values : Type-Descriptor x State-* Value 

Function type -values gives the set of values associated with a type location given a state: 

type-values : Type-location x State — ► P Value 

V/ : Type-location ; S : State • type-values(l , S ) = 
descriptor -values(snd(thestore(S).types(u)) ) S) 

Note that these sets of values might change over time as the information about a type is updated. 

3.5,1 Subtypes and Constraints 

A subtype is a combination of a type, a constraint, and certain attributes [3.2(8)]. There are in fact 
two sorts of subtypes; we will call them “partial” subtypes and “true” subtypes. Partial subtypes can 
contain unevaluated per- object constraints , for example, references to discriminants. These partial 
subtypes appear as the subtypes of components of a record with discriminants. When an object of a 
subtype is created, some of these per-object constraints are elaborated and the true subtype of the 
object and its components is determined. 

There are several cases where a partial subtype cannot be elaborated: in a variant record, per- 
object constraints in initially unused components are not elaborated; in an initialized object, none 
of the per-object constraints are elaborated. The Reference Manual is not completely clear on this 
point, and for now we will only consider per-object constraints that are references to discriminants. 

Partial subtypes appear only as the subtypes of components of types with discriminants; named 
subtypes, and the subtypes of objects, will always be “true” subtypes. 

The Reference Manual identifies three kinds of constraints: range constraints, index constraints, 
and discriminant constraints. In fact, the last two can also be applied indirectly, to an access 
type having a designated subtype to which the constraint would apply directly. (Only one level of 
indirection is allowed; given 

type Ai is access String; 
type A2 is access Al; 

an index constraint can be applied to Al, but not to A2.) We may find it useful to distinguish these 
indirect constraints from their direct counterparts. 

Constraint ::= no-constramt 

| range -constraint ((Range)) 

| index -constraint ((seq 1 Discrete-range)) 

| discriminant-constraint ((Binding)) 

| indirect-index -constraint (( seq x Discrete -range)) 

| indirect-discriminant-constraint ((Binding)) 

Some values satisfy a constraint: 
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_ satisfies _ : Value «-► Constraint 

V v : Value • t> satisfies no-constraint 

V v : Uatae • v satisfies range-Consiraint(R) <=> v belongs-to R 
array ~value( P, a) satisfies index -Constraint(S) <=> B = 5 

record _value(t , rf, r) satisfies discriminant -constraint (d') <=> d = d' 

Now we can define subtypes: 

Subtype 

type : Type— location 
constraint : Constrain* 
attn&utas : Attriiutas 


For every subtype, there is an associated set of values, namely the values of the associated type 
that satisfy the constraint. 

subtype -.values : Subtype — + State —+ P Vatae 

VS : State; s : Subtype | s.type G dom tae_stare(5). types • 

s?tatype_rataes(s, 5) = { v : Fatae | r G type_ratae$(s.type, 5) A v satisfies s. constraint } 

We use function subtype to create subtype values: 

subtype : Type-location x Constraint x Attributes — ► Sufctype 

s?tatype(/, c, a). type = t 
subtype^, c, a). constraint = c 
sut>type(t, c, a).attn6ntes = a 

3.5.2 Partial Subtypes 

Partial constraints are similar to constraints, except they may contain references to discriminants 
in place of values. 

Partial— value value ((Value)) \ discriminant -.ref ((Id)) 

Partial— discrete-range == Partial— value x ParttaLnatae 

Partial— constraint no-constraint 

| range -constraint ((Partial-discrete— range)) 

| index -constraint ((seq x Partial-discrete-range)) 
j discriminant —constraint l^ld -h Partial-value)) 

| indirect-index -constraint ((seq! PartiaLdiscrete-range)) 

| indirect-discriminant-Constraint((Id -++ Partial— valued 

A partial subtype combines a subtype and a partial constraint. (Using the subtype allows us 
to do a “dependent compatibility check” at the right time, and also gives us the needed attributes 
when we actualize.) 

Partial— subtype == Subtype x Partial— constraint 

Given a mapping from discriminant names to values, a partial constraint can be turned into a 
true constraint. 
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actualize -value : Binding—* PartiaLvalue -h- Value 
actualize -partial-range : Binding — ► ParfoaLcfiscreJeL-ran^e -+» Range 
a dualize -constraint : Binding — ► ParfmLcons^rain^ - h- Cons^rainf 
adua/ize.-Sii&type : Binding — ► PartiaLsubtype •+► 

ac<ua/ize_Wue / (ua/ue t>) = v 
ac<ua/ize_tta/«e / (rfiscrimman^re/ n) = /(n) 

actualize -partial-range f (l,h) = 

discrete-range(actualize -value f /, adualize-value f h) 

actualize -constraint f no-constraint = 7io_C0?isfram/ 

actaa/?ze_ams*ram< / (ran^e_consiram^(/, A)) = 

ran£e_cems*ram/(ac<ua/tze_parfoa/_ran0e / (/, A)) 

ac<ua/ize_ constrain/ / (jnde;r_C0ns/ram2 s) = 

znrfe2r_con5iraini((ac<tia/«2e_pariia/_ranye /) o 5 ) 

ad«a/^e_con5^ra2fi^ / (iiscnminan*_cc>tts*rani< d) = 

djscrimman/_cons/rajn<((actaa/t2e_i>ahie /) o d) 

actualize -constraint f (indirect-index -constraint s) = 

indirect-index -Constraint((adualize-partial-range f) o s) 

actualize-constraint f ( indirect-discriminant-constraint d) = 
tnd*rec<_djscnmman*_ccmstfra2ni((ac<uahze_t;a/tte /) o d) 

adua/ize_su&type / s = 

H Subtype | type — s .type A 

constraint = actualize-constraint f s. constraint A 
attributes = s.aftni^es 

3.5.3 Derived Types and Classes 

A derived type is a new entity, but it generally uses a copy of the parent descriptor. The set of 
values of the derived type is then the same as the set of values of the parent type. However, when 
a derived type definition furnishes new discriminants or defines a type extension, a new descriptor 
is needed. 

The store records some information about derivation, by recording the (optional) parent type 
[3.4(1)] of every known type. 

parent : State — * ( Type-location -h- Type-location) 

parent(S) = { t, t' : Type-location \ fst(thestore(S)Aypes(t)) = some(t f ) } 

Type extensions are considered in Section 3.5.8. Abstract types are considered in Section 3.5.8. 1. 

3.5.3. 1 Derivation Classes 

The descriptor for a class_wide type has the form class-dsc(t), where t is the Type-location of the 
root of the class. The values of this type are the values of all types derived (directly or indirectly) 
from t: 


descriptor-values(class-dsc(t) } S) — 

U{ f : Type-location \ (u\u) E parent(SY • descriptor -values^i* > S) } 

The notions of [3.4.1(10)] are easily defined: 
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descendant , ancestor : State — ► {Type— location <— ► 7y/>e_/oca/ion) 

Mftima<e_gn cc5<or : Sta*e x Type-location -+* Type./ocahon 
| ancestor(5) = paren*(5)* 
descendant*?) = ancestor^) -1 
^ E dom //ie_store(S) .types => 

n/hma*e_ances/cr(?, <) = ((ran paren/(S)) O ances<or(S)) t 

3.5.4 Scalar Types 

Every scalar type records a base range, in addition to any other needed information. 

| base-range : Type-Descriptor -++ Range 

Scalar types are either discrete types or real types. A value of discrete type is simply an integer; 
a value of a real type is a rational number. 

Each scalar subtype determines a range, as specified in [3.5(6)]: 

range-of subtype : Subtype x Store -k Range 

<j. constraint ~ range— constraint (R) => range— of —subtype{c ) S) = R 

<t. constraint = no -constraint 

range-of —subtype{(T^ 6) = base -range{snd{the store{S) .types{cr , type))) 

3.5.4. 1 Enumeration Types 

The type descriptor for an enumeration type has the form enumeration-dsc(n) , where n : N\ gives 
the number of enumerands. 

The base range of the enumeration is the set of discrete values with position numbers between 0 
and 7i - 1 (inclusive). The values of an enumeration type are the values in the base range. 

base-range{enumeraiion-dsc{n)) = discrete -rang e{ 0, n - 1) 
descnptor-values(enumeration-dsc(n), S) = discrete -value (|0 . . n - 1|) 

3. 5. 4. 2 Character Types 

Character types are simply enumeration types. 

3.5.4. 3 Boolean Types 

Boolean types are simply enumeration types. 

3. 5. 4. 4 Integer Types 

There are three descriptors for integer types: 

• signed-integer-dsc{bf , bl,f , /), with bf , bff, l : Z satisfying (according to [3. 5. 4(7)]), 

1. bf < 0 < bl , 

2. 6/+6/E {-1,0}, and 
3- {/, /} C bf . . bl. 
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The base range of this type is bf . . bl. 

• modular -integer -dsc{m), with m : Ni. (The base range is 0 . . (m - 1) [3.5.4(7)]. 

• umversaUnteger-dsc{bf , bl) for bf,bl : Z (although the base range seems to be irrelevant 
here) . 

root_integer is just a particular signed integer type. 

In every case, the set of valid values of the type consists of all discrete values [3.5.4(6)J. 

descriptor -values{signed -integer-dsc{bf , blj, l), S) = discrete-value<\l\) U Invalid-value 
descriptor— values(modular-integer-dsc(m), S) = discrete- V alue( |Z|) U Invalid-value 
descriptor -values{univer sal-integer -dsc{bf , bl),S) = discrete-value(\Z\) U Invalid-value 
base— range(signed— integer— dsc(bf , bl,f, /)) = discrete— range(bf , bl) 
base-range(modular-integer-dsc{m)) = discrete-range(0, m - 1) 
base-range(universal-mteger-dsc(bf, bl)) = discrete-range(bf , bl) 


3.5.4. 5 Floating Point Types 

As acknowledged in the Ada 9X Rationale, the core language leaves the semantics of floating point 
operations largely unspecified. By contrast, the floating point annex (Annex G) is quite precise 
though some flaws in the annex will be noted below. Therefore our model has two parts, one for the 
core and the other for Annex G. 

The semantics of the Reference Manual refers to the underlying machine values and operations, 
and makes features of them visible, for example, in the values of attributes. We have attempted to 
model this semantics directly, so that it will be clear how to tell whether an actual implementation 
satisfies the semantic rules. This provides a model from the point of view of the implementor It 
would have been easier (and from some points of view, perhaps, preferable) to make a model from the 
user’s point of view: e.g., take the values of the attributes as given and simply state axiomaticaliy, m 
terms of the attributes, the resulting constraints on the values returned by the predefined operations. 
The user’s model is, of course, a consequence of the implementor s model. 

The descriptor for a floating point type has four components: 


float-dsc (( Ni x Rational x Rational x Implementation)) 

The first three components are provided directly by the type’s definition: the requested precision and 
the bounds of its constraint. The fourth component characterizes the chosen implementation of the 
type. The descriptor for an integer type contains a component with analogous information, namely, 
the bounds of the underlying base type. We could represent the fourth component in a fimtary way 
by listing the values of a large number of floating point attributes determined by the implementation. 
Instead, this component of the descriptor will consist of a model of the implementation itself, from 
which the attributes can be calculated. 


descriptor -values(float-dsc{n, v, v' , imp), S) — reaLvaluel) Floaty 

base-range(float-dsc(n , v, v ' , imp)) = inf (imp. ma. numbers) . . sup{tmp .ma. numbers) 


3. 5. 4. 6 The core model of floating point 

The values of a floating point type are rationals, with the possible addition of some extra things like 
signed zeroes or NaN’s. For now these extra possibilities are ignored. 
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Float == Rational U . . . 


There is a problem in the Reference Manual: The possibility of signed zeroes or NaN’s is incom- 
patible with [RM-83 3. 5. 7(8)], which says that the set of values for a floating point type is the set 
of rational numbers. 


3. 5. 4. 6.1 Machine arithmetics Elaboration of a floating point type declaration includes the 

choice of an appropriate Implementation (from some predefined non-empty finite set of them) to 
model the type. One component of an implementation is a machine arithmetic , which consists of a 
radix, a set of machine numbers, and relations modeling the predefined binary and unary floating 
point operations. Floating point operations will be modeled not as functions but as relations, in order 
to model their potential non-determinism. Some of the predefined binary floating point operations 
return floats and some return booleans; all unary operations return floats. It is convenient to add a 
special “return value,” overflow , to represent the possibility of overflow: 

FloatResult overflow \ result ((Float)) 

BinOpFloat == Float 2 *■+ FloatResult 
BmOpBool == Float 2 <-► Boolean 
UnOp == Float FloatResult 


It will also be handy to have an operation that extracts the (non-overflow) Float values from a set 
of FI oat Re suits'. 


floats-of : P FloatResult — ► Float 
floats-of(X) = result^ (\X D 


In schema Machine Arithmetic: 


• radix is the radix of the machine representation 


• numbers is the set of machine numbers — that is, the set of storable values that will “fit” in 
any variable of the type. 


• plus, equals , . . are relations modeling the predefined floating point operations; convert rep- 
resents type conversion of an arbitrary real value to a machine number of this arithmetic. 


Notice that operations like plus are not restricted to returning machine numbers of the type as 
values. The machine numbers represent the storable values of the type, but operations may return, 
e.g., extra-precision values that are not immediately rounded. 
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Machine Arithmetic — 

radix : Ni 
numbers : F x 
p/t /5 : BinOpFloat 

equals : BmOpBool 

uminus : UnOp 

convert : UnOp 
float -outcomes : P Float 

float-outcomes = 

nwm&er$ U /?oa*s„ 0 /(ran p/us) U . . . uy?cal!s_0/(ran convert) 
(/?oa*_ 0 t/<C 0 mes) 2 C dom p/us 

(/7oa/_0u/c0raes) 2 C dom egua/s 

float-outcomes C dom uminus 

Float C dom convert 

ran convert C ma. numbers 

sup(numbers) < — inf (numbers) 


The axioms involving float-outcomes are technical conditions guaranteeing that the (non-overflow) 
results of any operation can legitimately be passed as arguments to any of the others. 

The concluding inequality is all we can represent formally of paragraph 3. 5.7(8): 

The base range (see 3.5) of a floating point type is symmetric around zero, except that 
it can include some extra negative values in some implementations. 

Note: It would probably be reasonable to suppose that the machine numbers are (roughly) sym- 

metric in a stronger sense: the set of machine numbers between -sup(numbers) and sup(numbers) 
is closed under additive inverse. The Reference Manual does not require this. 

Note: This definition could be shortened if we simply assumed that the relations modeling all 

the predefined operations were total. One reason for not making that assumption is the desire 
that there be an obvious relation between this definition and actual floating point implementations. 
In representing an actual implementation as a machine arithmetic two principles apply: First, the 
plus relation modeling an actual implementation of + should contain ((ar,y),i) if z is the actual 
result (presumably computed by the hardware in some register) of summing x and y \ and should 
also include ((r, y),z') for every possible “perturbation” z' of 2 obtained by moving 2 to and from 
registers of other precisions or to and from storage. (Similar considerations apply to all other 
operations.) Second, it is sound to model an implementation by using relations that are supersets 
of this “minimal” model. 


3. 5. 4.6. 2 Par am eters of floating point implementations We need two kinds of specifica- 
tions for describing aspects of floating point implementations: A MachtneParam is a specification 
requiring that certain floating point numbers actually be machine numbers of an implementation. It 
does not constrain the semantics of the floating point operations. The “representation-oriented at- 
tributes” of a type will be defined to return, essentially, the “strongest” MachineParam satisfied by 
the type’s implementation. (Strictly speaking, we will define what it means for a machine arithmetic 
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to satisfy a MachineParam , and a machine arithmetic is only one component of an implementation.) 
An AccurParam does constrain the behavior of the floating point operations. Annex G will define 
the u model-oriented attributes” of a type to return, essentially, the strongest AccurParam satisfied 
by the type’s implementation. The core of the Reference Manual says very little about the relation 
between the implementation and these model attributes. 

3. 5. 4. 6. 3 Machine parameters A MachineParam is a triple whose elements are interpreted 
as, respectively, a mantissa length, a minimum exponent, and a maximum exponent. 

MachineParam ... — — 

mantissa : Ni 

emtn : { i : N | i < 0 } 

emax : 


A machine arithmetic satisfies a MachineParam if all the canonical numbers defined in terms of 
these parameters (and of the machine arithmetic’s radix) are machine numbers: 

sat-float-param : M achxne Arithmetic «-* MachineParam 
(ma,/p) £ sat -float -param <=> 

BoundedCanonical(ma .radix , fp .mantissa , fp .emin , fp .emax) C ma. numbers 

The BoundedCanomcal numbers are defined in Section 3. 5. 4. 6. 4. Note that sat-fl oat-pa ram does 
not constrain the operations of the machine arithmetic in any way. 

A first MachineParam is “improved by” a second if the second is at least as restrictive a specifi- 
cation as the first. 

_ improved-by _ : MachineParam <-► MachineParam 

(pi , emin i, emax i) improved-by (p 2 , emin 2 , emax 2 ) <=> 

Pi < P 2 A emini > emin 2 A emax \ < emax 2 

A MachineParam fp for ma is maximal if ma satisfies fp but satisfies no strict improvement of 
fp. The function max -mach-params(ma) returns the set of all maximal MachineParams satisfied 
by ma. 


m ax mach—params : M achxne Arithmetic —> F MachineParam 

max-mach-params(ma) — 

maximal(restrict({ mattr \ sat-float-paramfaa, mattr) }, 

-improved-by -)) 

The generic constant maximal returns the set of maximal values of a relation. The generic constant 
restrict returns the result of restricting both the domain and range of a relation to the same set. 
These constants are defined in Section 3.1. 

There is a problem in the Reference Manual: [RM-83 A. 5. 3] defines the representation-oriented 
attributes of a floating point type. They are intended, collectively, to denote a “best” MachineParam 
satisfied by the machine arithmetic of the type, but the definitions given there are not quite right. 
In particular, if ma is the machine arithmetic chosen to implement type T, the rules of the Reference 
Manual do not guarantee that 

ma sat -float -param (T'machine^antissa, T'machine_emin, T'machine_emax) 
although this is surely one intended consequence of the rules. 
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3. 5.4. 6.4 Representations of floating point The canonical representions of floating point 
numbers are defined in the core semantics, Appendix A. 

Our definitions will represent fractions with radix r and mantissa length m by length- m sequences 
of the “digits” 0, . . . , r — 1. A normal representation is a representation whose first element is non- 
zero, or which consists solely of zeroes. 

reps : Ni x Ni Pseq(N) 
normal-reps : Ni x Ni — ► Pseq(N) 

reps(r , m) = 1 . . m — ► 0 . . (r — 1) 
s E normal -rep s(r, m) O s E reps(r, m) A 
5 ( 1 ) = 0 => V i : dom(s) • s(i) = 0 

The operation fraction-value returns the fraction represented by the sequence s in radix r — that 
is, the “decimal” .s(l)s(2) . . . s(m), understood as a literal in base r. 

fraction-value : Nj x seq(Ni) — ► Rational 
fractions : Ni x Ni — > P Rational 
normal-fractions : Ni x N\ — ► P Rational 

fraction-value(r , s) = s(i) * r~ l 

fractions (r, m) = /racfion_t;a/«e(|rcps(r ) m)D 
norma/_/racf?c>ns(r, m) == fraction-value(\normal-rep$(r , m)0 

The model floating point numbers are those suitably definable in scientific notation, i.e., as 
fractions times powers of the radix. 

make-floats : P Rational x Z x Ni — ► P Rational 

make-floats(fracs , exps, rad) = 

{ / : /ia/iona/, e : Ni | / E /racs A e E exps • ±/ * rad € } 

We are principally interested in two classes of “canonical” floating point numbers: 

Canonical : Ni x Ni x Ni — ► P Rational 
BoundedCanonical : Ni x N\ x Ni x Ni — ► P Rational 

Canonical(rad , manf , emin) = 

make-floats(normal-fracttons(rad ) mant), { i : Z | emin < i },rad) 
5onndedCanonica/(rad, manf , emin, emax) = 
make-floats(normal-fractions(rad , man<), 

{ t : Z | emin < 1 < emax }, 
rad) 

3. 5. 4. 6. 5 Implementations An /mp/emenfafton consists of a machine arithmetic, a MachineParam 
modeling the representation-oriented attributes of the arithmetic, and a boolean indicating the re- 
sponse to numeric overflow. The properties of the machine arithmetic do not uniquely determine 
the appropriate MachineParam . 

Implementation 

ma : Machine Arithmetic 
machine-attr : MachineParam 
overflows : Boolean 

machine-attr E max-mach-params(ma) 
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An AccurParam is a 6-tuple whose elements are interpreted as a radix, a mantissa length, a 
minimum exponent, the bounds for a safe interval, and an indication of whether overflows are to 

be reported. (The constraints defined by the other parameters are interpreted more strictly if the 
“overflows” flag is true.) 

AccurParam _____ 

radix , mantissa : Nj 
emm : { i : N | i < 0 } 
sfirst , slast : Float 
overflows : Boolean 


It is convenient to have an abbreviation for the set of safe numbers that an AccurParam defines. 
safe : AccurParam — ► P Float 
safe(ap) = ap. sfirst . . ap. slast 

We will formalize an essential notion of Annex G with -has-.accuracy— , which says what it means 
for an implementation to satisfy an AccurParam. From the core model, we can extract only some 
minimal properties of this relation, expressed in the weaker notion -has^weak-acc^: 

— has—weak^acc _ : Implementation <— * AccurParam 
-has -accuracy _ : Implementation <-* AccurParam 

imp has~iveak_acc ap o 

ap. radix = imp. ma. radix A 
ap .mantissa < imp .machine -.attr .mantissa A 
ap.emin > imp .machine ^attr .e min A 
{ ap. sfirst, ap. slast } C ma. numbers A 
imp. overflows = ap .overflows 
imp has-accuracy ap o imp has -.weak -.acc ap 

For any implementation imp , in Annex defines modeLattr(imp), a unique “best” AccurParam 
satisfied by an implementation. All we can say in the core semantics is that imp satisfies the weak 
accuracy requirements imposed by model ^attr (imp). 

model^attr : Implementation — ► AccurParam 

imp ka$-weak_acc model^attr(imp) 

More precisely, Annex G defines model _attr (imp) to be a particular maximal ap such that imp 
has-_accuracy ap. 

The maximum number of decimal digits of accuracy is uniquely determined by the model-oriented 
attributes of the implementation. 

digits : Implementation — ► Ni 

imp. radix = 10 O digits(imp) = model _attr (imp). mantissa 
imp. radix ^ 10 O 

digits(imp) = ceiling( 

( model— attr(imp) . mantissa * log(\0)/ log(vnp .ma. radix)) + 1 

There is a problem in the Reference Manual: This definition of “digits” is not given anywhere in 
the Reference Manual. It is surely the intended one, but it does not seem to follow from anything 
in the Reference Manual. 
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There is a problem in the Reference Manual: Section A.5.3(67-68) defines the value of S'HodelJJantissa 
in incompatible ways, depending on whether or not the implementation “supports Annex G The 
same is true for S’ModeLEmin. In consequence, an implementation can be valid for Core+G but no 
valid for the Core alone. (By contrast, the core semantics makes the semantics of the model-oriented 
attributes 'Sale-First and 'Sale-Last upward compatible by leaving them implementation-defined.) 

The definitions of S'Model_Mantissa and S'ModeUEmin given here are weaker than those of the 
core semantics. We require only that 

S'Model—Mantissa < S'MachineJKantissa 
s'Hodel_Emin > S'Machine_Emin 


(See the definition of -has-weak-acc- .) 

These definitions make the core semantics compatible with Annex G. In addition, they capture 
the only information that the present version of the Reference Manual allows a user to rely on across 
all implementations. 

3 5.4.6. 6 Satisfaction of a type definition A floating point declaration supplies a requested 

precision (a value of N) and, optionally, a constraint (two Rational*). The accuracy of the types 
implementation must be at least as great as the requested precision and the safe range of the 
implementation must include the interval defined by the constraint. This requirement is captured 
by the definition of saL-float-def. 

The Reference Manual says that any such implementation may be chosen. We represent h 
particular strategy that the implementation uses for choosing the implementation (such as choosing 
the coarsest acceptable implementation type) by the relation implements floai-def. The judgem 
defining elaboration of a type definition selects an implementation satisfying i mplements-float-def. 
All the reference manual requires of this relation is that it be consistent with sat-float-de]: 


sat-float-def , implements -float -def : 

Implementation <— ► (N x Rational x Rational ) 

(imp, ( n , L, R)) £ sat-float-def => 

L . . R C m odel-attr (imp) .s first . . model-attr(imp).slast A 
m < digits(imp) 

implements— float— def C sat— float— def 


3. 5.4.6. 7 Attributes If imp is the implementation chosen for type T, then the basic implementation- 
oriented attribute values of T are given as follows, where we let imp. machine -attr - (mant, emm, emax). 


T * Machine-Radix = 
T 9 Machine-Mantissa = 
T 9 Machine_Erain = 
T > Machine_Emax “ 
T’Base'First = 
■PBase'Last 


imp. ma. radix 
mant 
emin 
emax 

min(imp .ma .numbers) 
m ax (imp .m a .numbers) 


i 'Base' Lash — / . n „ 

The limits of the base range are the least and greatest machine numbers. This follows from 3.5(5) 


The base range of a scalar type is the range of finite values of the type that can be 
represented in every unconstrained object of the type 


and from 3. 5. 7(8) 

The machine numbers of a floating point type are the values of the type that can be 
represented exactly in every unconstrained variable of the type. 
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The basic model-oriented attribute values of an implementation imp are given as follows (where 
we let model „attr (imp) ~ ( Mant ) Emin ) sfirst , slast)): 


T'Model_Mantissa = Mant 

T'Model__Emin = Emin 

T'Saf e_First = sfirst 

T'Saf e_Last = slast 

T'Base 'Digits = digits(imp) 


The definition of T ’Base 'Digits is something of a guess. 

Note: The definitions of various attributes, such as S 'Model (for floating point subtypes) and 

S' Machine (for fixed and floating point subtypes) say that the value returned is obtained “by 
rounding or truncating” the operand “to either one of the adjacent” model or machine numbers, as 
appropriate. It is not clear from this language whether these operations are non-deterministic. 


3. 5. 4. 7 Annex G 

Annex G defines some more precise constraints on the floating point operations. 

3.5.4. 7.1 Model numbers and accuracy An accuracy parameter determines a set of model 
intervals (intervals bounded by the associated canonical real numbers) and associates a model interval 
with each bounded set (namely, the smallest model interval that contains it): 

Mode (Intervals : AccurParam — ► P Float 
ModellntOf : P Float x AccurParam -h- P Float 

u £ Modellntervals(ap) <=> 

3 /o, hi : Float • 
u = lo . . hi A 

{ lo,hi } C Canonical(ap. radix , ap. mantissa , ap.emin) 

ModellntOf (X , ap) = f){ u £ Modellntervals(ap) \ X C u } 

Given a “paradigm” operation / and an accuracy specification ap } we define for each x the set of 
results that approximate f(x) to within the demands of ap — namely, the model interval of the set 
that results from applying / to the model interval of x. (The same applies, mutatis mutandis , to the 
binary operations.) All definitions follow the same pattern, but the type restrictions of Z require us 
to provide separate definitions for unary operations, binary operations returning floats, and binary 
operations returning booleans. 

ResultUnOp : ( Float — ► Float ) x AccurParam — ► ( Float — ► P Float) 

ResuliBinOpFloat : ( Float 2 — ► Float) x AccurParam — ► ( Float 2 — ► P Float) 

ResultBinOpBool : ( Float 2 — ► Bool) x AccurParam —► ( Float 2 — ► P Bool) 

Result UnOp(f y ap) = 

X x : Float • 

ModellntOf (f{\ Mode lint Of ({x} , ap)|), ap) 

ResuliBinOpFloat (f , ap) = 

A x,y : Float • 

ModellntOf (f(\ ModellntOf ( { x } , ap) x ModellntOf ({y} ) ap)D, ap) 
ResultBinOpBool(f , ap) = 

A x,y \ Float • 

ModellntOf (f(\ModelIntOf({x} , ap) x ModellntOf ({y} , ap)D. a P ) 

Operands are “safe for” a paradigm operation if they and all their approximate results are safe. 
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SafeForUnOp : ( Float — ► Float) x AccurParam — > P Float 
SafeForBinOpFloat : ( Float 2 — ► F/oat) x ylccwrParam — + P Float 2 
SafeForBinOpBool : (F/oat 2 — ► Poo/) x AccurParam —+ P Float 2 

SafeForUnOp{f, ap) = 

{ x E sa/e(ap) | Fesu/t//nOp(/, ap)(x) C sa/e(ap) } 
5a/eFor5mOpF/oa^(/, ap) = 

{ (x, 2 /) E (sa/e(ap)) 2 | iicsttW5mOpF/oa<(/, ap)(x,y) C $a/e(ap) } 
5a/eForPinOpPoo/(/, ap) = 

{ (x, y) G (sa/e(ap)) 2 | Fesu/tPinOpF/oat(/, ap)(x,y) C safe(ap) } 


A UnOp approximates a “paradigm” function to within some accuracy specification if it associates 
all operands with results that are acceptable approximations to that function. The same goes for 
BmOpFloats and BinOpBools. In particular, safe operands may not return an overflow ; and if the 
“overflows” flag is true, unsafe operands must return either an approximately correct result or the 
overflow token. 

-Approx UnOp- : UnOp <-► ( Float — ► Float) x AccurParam 
-Approx BinOp Float- : BinOpFloat <-► {Float 2 — > Float) x AccurParam 
— Approx BinOp Bool— : BinOpBool «-*• {Float 2 — ► F/oat) x AccurParam 

op Approx UnOp (/, ap) <=> 

V 2 E dom op • 

(x E SafeForUnOp{f , ap) => 
overflow £ op(j{ x }D 
A 

floats -of{op(\{ x }D) C ResultUnOp{f , ap)(x)) 

A 

(ap.ouer//ou;s = true => 

/?oats_o/(op(]{ x }[)) C ResultUnOp{f , ap)(x)) 
op Approx Fin Op F/oat (/, ap) <=> 

V(x, y) E dom op • 

((x, y) E SafeForBinOpFloat{f , ap) => 
overflow (fc op(]{ (x, y) }[) 

A 

//oats_o/(op(|{ (x,y) }[)) C ResultBmOpFloat (/, ap)(x, y)) 

A 

(ap.over/Jotos — true => 

//oats_o/(op(]{ (x,y) }D) C Result BinOp Float {f y ap){x, y)) 
op Approx BinOpBool (/, ap) 

V(x, y) E dom op • 

((x, y) E SafeForBinOpBool{f , ap) => 
overflow g op(]{ (x, y) }D 
A 

/toats_o/(op(]{ (x, y) }D) C Re suit BinOp B ool{f , ap)(x, y)) 

A 

(ap.ouer//ou;s = true => 

y?oats_o/(op(|{ (x,y) }[)) C ResultBinOpBool{f , ap){x, y)) 


We can now define the property _i has-accuracy „ as the assertion that each machine operation 
approximates the appropriate paradigm function to within the given accuracy parameters: 
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imp has— accuracy ap o 

imp has-weak^acc ap A 

imp. ma. plus Approx BtnOpFloai (+, ap) A 

imp. ma. equals Approx BinOpBool (=, ap) A 

imp. ma. convert Approx UnOp (id Float, ap) 


3.5.4.T.2 Model-oriented attributes To define modeLattr we choose a particular maximal 
AccurParam satisfied by an implementation. (Note: The definitions below do not follow the defini- 
tion in version 5.0, which is incorrect, but Ken Dritz’s subsequent reworking of version 5 0 ) 


best— maiit : P AccurParam — » P AccurParam 
best-emin : P AccurParam — ► P AccurParam 
best-first : P AccurParam — > P AccurParam 
best— last ; P AccurParam — ► P AccurParam 
besi-ap : P AccurParam P AccurParam 

best-ap(X) = 

best-last ( best -fir st[best-emin(best-mani(X)))) 
model -atir [imp) = 

n ap -.AccurParam • ap £ best a p(ap' : AccurParam \ imp has_accuracy ap')ap £ besi.mant(X) o 

dp E X A V ap : A • ap .mantissa > ap f .mantissa 
ap G 6e5J_emin(Af) 

ap £ X A V ap' : A' • a/r.emtn < ap f .emin 
ap G 6e$/_/zrstf(A r ) <=> 

G A" A V ap' : X • < ap'.s/jrstf 

ap G tas^/as^A") 

G I A V apM i ap.slast > ap' .slast 


There is, of course, exactly one best-ap: 


#best-ap({ ap : AccurParam | imp has -accuracy a/?}) = 1 


3.5.5 Array Types 


The descriptor for an array type has the form array_dsc(i, c), where i : seq Subtype is 
discrete subtypes (the index subtypes ) , and c : Subtype is the component subtype. 


a sequence 


of 


descriptor-values(array-dsc(i, c), S) = 

{ B . Index.— bounds , v : (seq Value) -++ subtype— value s[c y S) 
| Array (5, v) G Value A B — rang e-of subtype o i 
• ,4rray(i?, v) } 


3.5.5. 1 String Types 

String types are just particular array types. 


3.5.6 Discriminants 

Discriminants are specialized components of some composite types. We incorporate discriminants 
(which might be null) into the descriptor for every type that can have discriminants, in order to 
avoid a tedious duplication of definitions in similar cases. 
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This model does not account for access discriminants. 

Discriminant— descriptor == Id — > Subtype x optional Thunk 


discriminant-values : Discriminant-descriptor x State -* P Binding 
discriminani-values(d,S) = 

{ / : adorn d — Values | Vn € adorn d • f{n) G subtype-values(first(d -n),S ) } 


3.5.7 Record Types 

It seems like a waste of effort to describe records with discriminants separately from records without 
discriminants, as there is a good deal of overlap in the two cases. Thus, we give every record type 
descriptor discriminants (which may be null). 

Similarly, it seems like a big duplication of effort to describe tagged record types separately 
Thus, we will give every record descriptor a tag (which may be null in the case of an untagged 

record). 

Component-list-descriptor == 

(Id PartiaLsubtype x optional Thunk ) x optional Variant-descriptor 

A record type descriptor consists of a description of the discriminants (if any) and a component 
list description The values of such a descriptor are records with fields for the discriminants, and 
fields for the other components. The subtypes of these latter fields (and even the exact fields present) 
may depend on a value of a discriminant. 

descriptor-values(record-dsc(t,DA,CL),S) = 

{ d,r : Binding \ d G discnmmant-values(DA, p) A r G CL-values(CL, d,S) 

• record(t , d, r) } 

A binding giving the values of the discriminants is given to function CL-values, so that the actual 
subtype of each component can be determined. 

CL-values : Component-list-descriptor x Binding x State -* P Binding 


CL-values{( A, V),d, S) = {/, i’ : Binding | dom/ - adorn A A 

(Vn G dom / */(n) £ Subtype-values(actuahzesubtype(jirst(A ■ n), a), £>)) 
v G Vanant-values(V , d,S) 

• /Ur } 


3.5. 7.1 Variant Parts and Discrete Choices 

A variant descriptor has the Id of the discriminant of the variant part, and a mapping from the 
possible values of this discriminant to component list descriptors. 

Variant-descriptor == Id x ( Discrete -value -•+ Component-hsi-descnptor) 


Variant-values : ( optional Variant-descriptor ) x Binding x State — P Binding 
Variant-values(none , <f, S) = {0} 

d(n) G dom f => Variant-values(some(n,f),d,S) = CL-values(f(d(n)),d,S) 
d(n) & dom / => Variant-values(some(n,f ), d,S) = {0} 
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3.5.8 Tagged Types and Type Extensions 

The model for tagged types has not yet been developed. 

3.5.8. 1 Abstract Types and Subprograms 

[AARM 3. 9. 3(8. a)] asserts that there are no values of an abstract type. But it is possible to have 
subprograms for such subtypes, and for non-abstract descendents to inherit them. If we want to say 
something about the meanings of such subprograms, we probably need to talk about the values of 
the parameters. (In some sense, these are parameters of type T’Class.) 

On the whole, it probably seems easiest to use a model of values as though the type were not 
abstract; we can also treat abstract subprograms as though their bodies raised Program_Error. 

3.5.9 Access Types 

The descriptor for an access type has the form access-d$c(s, m), where s : Subtype-location describes 
the designated subtype of the access type, and m : Access-mode describes the access mode. 

Access-Mode ::= constant-access \ all-access \ pool-access 

A value of an access-to-object type is either a null value, or a view of an object of the designated 
subtype: 

descrtptor-values(access-dsc(s ) to), S) = 

{access-value(none)}\J 
{ access -value(some{objeci-V%ew(l, s'))) \ 

1hestore(S).objects(l) E subtype-values(thestore(S).subtypes(s) ) S) } 

3. 5. 9.1 Incomplete Type Declarations 

The descriptor incomplete describes an incomplete type. When the full type definition for the type 
is elaborated, the type environment is updated to reflect the appropriate descriptor for the type. 

Note that there is an issue about the first subtype of an incomplete type; it is constrained if 
there is no discriminant part. However, the first subtype corresponding to the full definition may 
be unconstrained. (See comment 94-3901. c.) 

There are no values of an incomplete type. 


3.6 States 

A state combines a store, an external state, and control flow information (in the usual cases), or is 
erroneous or unpredicted . We use the state unpredicted in those cases where our semantic definition, 
in the interests of simplicity, makes no prediction about the effect of a program (even though the 
Standard defines the effect, or calls it implementation-defined ) . 

State ::= normal ((Store)) 

| exception(( Except tonld x Store)) 

] exit ((Loop -Id x Store)) 

| proc-return ((Store)) 

\ func-return ((Value x Store)) 

| intermediate ((Store)) 

| erroneous 
| unpredicted 

Function thestore gives the store associated with a state. 
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Chapter 4 

Judgements 


This section summarizes the domains and judgements used in the definition of Ada 9X seman- 
tics. The details of the domain definitions are given in Chapter 3. The formal definitions of these 
judgements are given in later sections. 

4.1 Domains 

The definition is based on the concepts, domains and support functions, introduced in Chapter 3. 
Specifically, it uses the domains listed in Table 4.1 

All of these domains are generated by term algebras (subject to the constraints defined in Chap- 
ter 3). Constructors for these domains are given below. In addition, the domains of component 
associations and environments are defined as follows: 

Comp Assoc = list((Icf x (Subtype x optional( Thunk)))) 

Environment — (M -++ View) 


Also the signatures for all functions (other than contractors) and predicates are given. Note that 
these signatures are those used in the Prolog representation of judgements and may differ from those 
given in Chapter 3. 


4*1,1 Types 

The structure of a type is given by a type descriptor of the form: 
type Type 

enum-type : integer — ► Type 
modular-type : integer — ► Type 

signed— integer-type : integer x integer x integer x integer — ► Type 
universal-integer-type : integer x integer Type 
array-type : list(Sa6type) x Subtype — + Type 
class-type : Type— location — ► Type 

access-type : Subtype-location x Access-modifier — ► Type 
func-profile : (Id A Parameter) x Subtype — ► Type 
proc-profile : (Id Parameter) — ► Type 

incomplete-type : Discriminant — ► Type 

record-type : optional( Type-location) x Discriminant x Record-fields — ► Tppe 
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Access— modifier 

access (type) modifier 

Action 

executable actions 

Attributes 

subtype attributes 

Bool 

truth values (non-Ada) 

Choice 

choices 

Constraint 

constraints 

Discriminant 

discriminants 

Exld 

internal names for exception identifiers 

Record— fields 

record fields including variants 

LValue 

L-values (addresses) 

Loop Id 

internal names for loop identifiers 

Mode 

parameter modes 

Object-location 

addresses of top-level objects 

Object— mode 

indication of constancy and aliasing 

Partial-constraint 

partial constraints 

PartiaLsubtype 

partial subtypes 

Partial-value 

partial values 

Parameter 

formal parameters 

Range 

discrete and real ranges 

State 

state of a computation 

Store 

model of memory 

Subprogram 

subprogram values 

Su bp rog ra m_/ abel 

unique tags for subprogram access values 

Subprogram— location 

addresses for subprogram values 

Subtype 

subtypes 

Subtype -location 

addresses for subtypes 

Thunk 

an expression with its declaration environment 

Type 

type descriptors 

Type— location 

address space for type information 

Value 

runtime values 

Variant 

variants 

View 

views 


Table 4.1: Domains used in the judgements 
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Descriptors of this form are stored in the state and are accessed by unique addresses of sort 
Type-location. A derived type is represented by a new name for an existing type descriptor. T e 
use of type names has the advantage that it is easy to deal with cyclic types and type completion. 

It has the disadvantage that types can be understood only in the context of a state. 

The domain Type-location contains constants that represent the predefined types of the language: 

typ e Type— location 

boolean-tn : Type-location 
character-tn : Type— location 
universai_infceger_fcn : Type-location 
universal-real-tn : Type-location 
root-integer-tn : Type-location 

In the case of tagged types, values of Type-location are used as unique tags. The optional 
Type-location component of a record type descriptor defines the tag of the parent type. Values of 
sort Type-location are related by the ancestor relation which represents both the derivation and class 

hierarchy: 

ancestor{State , Type— location, Type— location) 
descendant(State, Type— location, Type— location) 
ultimate-ancestor(State, Type-location, Type-location) 

Access modifiers are used in the descriptors of access types with the obvious meaning. 

type Access-modifier 

constant-access : Access-modifier 
alLaccess : Access-modifier 
pool-access : Access-modifier 

Discriminants are represented as follows: 

type Discriminant 

discr : (Id A ( Subtype x optional( Thunk))) -»• Discriminant 
{) : Discriminant 

Two discriminants can be combined using: 

discriminant-union : Discriminant x Discriminant — ► Discriminant 
A thunk represents an expression together with its declaration environment, 
type Thunk 

thunk : Environment x Exp — * Thunk 

A component list represents actualized record fields, i.e., record fields that do not contain partial 
information that depends on discriminant values. 

type CompAssoc = list((Jcf x (Subtype x optional(TAuni)))) 

The fields of a, possibly discriminated, record type are represented by the domain 

type Record-fields , 

fields : (Id ( Partial-subtype x optional( Thunk))) x optional((fd x Variant)) — Record-fields 

which includes the proper fields (maybe partial) as well as any variant. 
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Component associations can be constructed from discriminant values and partial component lists 
or variants: 

ac t ualized-complist : (Id Value) x list((/d x (PartiaLsubtype x option^ Thunk)))) - Comp Assoc 

actualized-components : (Id Value) x Record-fields — CompAssoc 
ac tualized- varian ts : (Id -k Value) x (Id x Variant) — CompAssoc) 
append-components : CompAssoc x CompAssoc CompAssoc 

A variant part is represented by a pair (Id x Variant) where the identifier specifies the name of 
the discriminant and the second component represents the actual fields: 


type Variant 

variant : list (( Choice x Record— fields)) — ► Variant 
() : Variant 

Given a discriminant value, the actual record fields of a variant are defined by the predicate 

the-variant( Variant , Value , Record-fields). 

Variant parts are combined using function 

variant-union : optional (Id x Variant) x optional (Id x Variant) — ► optional (Id x Variant). 
The representation of subprogram access types uses parameter descriptors of the form: 
type Parameter 

formal : Mode x Subtype x optional( Thunk) — ► Parameter 
where modes are given by: 

type Mode 

in-mode : Mode 
out-mode : Mode 
in-out-mode : Mode 

The following predicates define the set of values of a given type (descriptor): 

cLvalue(State , Record-fields, (Id -*+ Value), (Id -++ Value)) 
discriminant-vaIue(State } Discriminant , (Id -k Value)) 
variant-values(State, optional((Id x Variant)), (Id -++ Value), (Id -++ Va/ue)) 
descriptor_vaiue(S<ate, Type, Va/we) 

4.1.2 Values 

The representation of values is straightforward using the definition 

type Value 

invalid-val : Value 
discrete- val : integer — ► Value 
reaLval : real — ► Va/ue 

access-val : View x opt\ona\( Subprogram-label) -+ Value 
null : Va/ue 

record-val : optional(Type_/oca/zon) x (Id -44 Va/ue) x (Id -44 Va/ue) — ► Va/ue 
array-val : !ist( tfanye) x (list( Va/«c) ■++ Value) -4 Va/we 
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The term access_vai(. . .) is used for access to object and access to subprogram values. In the 
latter case, each time a subprogram access is computed a new unique subprogram label 

type Subprogram— label 

is generated. This label is needed to properly model equality of access to subprogram values. 

Note that access values are views. This representation is used to determine the actual subtype 

of an access value. 

Ranges are represented as pairs of values in the obvious way. 
type Range 

discrete-rng : integer x integer Range 
real-rng : real x real — > Range 

The following functions are defined for ranges. 

low-bound : Range — ► Value 
high-bound : Range — ► Value 
make-range : Value x Value — ► Range 
base-range : State x Type — * Range 
indices : Ust(Range) — * set (list( Value)) 

The latter function defines the set of all index vectors that fit a list of (index) ranges. 

Sets of (scalar) values are represented using the domain 

type Choice 

choice-range : Range — ► Choice 
choice-value : Value — ► Choice 
choice-lst : list (Cho ice) — ► Choice 
choice-default : Choice 

The following are predicates on values 

access- vaiue( Value) 
array- vaiue( Value) 
belongs-to( Value , Range) 
composite-value{ Value) 
covers( Value , Choice, Boot) 
discrete-value( Value) 
elementary-value( Value) 
real-value{ Value) 
safcisfies( Value , Constrain/) 
scaJar_vaiue( Va/ue) 


4.1.3 Subtypes 

The definition of subtypes follows the description provided by the Reference Manual, 
type Subtype 

subtype : Type— location x Constraint x Attributes — ► Subtype 

Access to the underlying type is indirect through a type location. The present version of the 
semantics does not use any subtype attributes. 

type Attributes 

not_used : Attributes 
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Functions defined for subtypes are 


range-ofsubtype : State x Subtype — ► Range 
ranges-ofLsubtypes : State x list (Subtype) — ► list( Range) 
typestruct : State x Subtype — ► Type 


Constraints are 


type Corjs^rand 

no_constraint : Constrain* 
range_cojistrainfc : Pan^e — ► ConsJrainf 
inc/ex_cons train t : list (Range) — ♦ Constrain* 
discriminant-consfcraint : (Id -++ Fa/ue) — ► Cons/rain/ 
indirect_index_constrainfc : list (Range) —+ Constraint 
indirect-discriminant-constraint : (Id -++ Ta/iie) — ► Constraint 


In the case of discriminated record types, component subtypes can be partial if they depend 
on discriminant values. This leads to the following definitions of partial counterparts of values, 
constraints, and subtypes. 


type PariiaLvalue 

p_vaiue : Value — ► P artiaLvalue 
discriminant-ref : Id —+ PariiaLvalue 


type PartiaLconstraint 

p-no-constraint : PartiaLconstraint 

p_range_constrajnt : ( PariiaLvalue x PariiaLvalue) — ► PartiaLconstraint 
P— index-constraint : Y\st(( PariiaLvalue x PariiaLvalue)) — ► PartiaLconstraint 
P-discriminanLconstraint : (Id -++ PariiaLvalue) — ► PaHtaLcons^rain/ 
P—indirecfc—index—constraint : list((PartiaLva/tte x PariiaLvalue)) — ► PartiaZ-Cons/rain/ 
p_indirec£_discnmin an t_cons train t : (Id -++ PardiaLva/ue) — ► PartiaLconstraint 


type PartiaLsubtype 

psubtype : Subtype x PartiaLconstraint — ► PartiaLsubtype 


Given a discriminant constraint, partial entities can be actualized. This process is defined by the 
functions: 


actualized-partiaLrange : (Id -++ Value) x (Par/iaLva/ae x PariiaLvalue) — ► Pan^e 
actuaI;zed_range_Jjst : (Id -+► Fahxe) x list((PaJdialLua/tte x Par<ia/_va/ue)) — + list( Range) 
actualized— value : (Id -h- Va/we) x ParfzaZ_i>a/?/e — ► Va/ac 
actuaiized_constrainfc : (Id -+► Tah/e) x ParfoaLcons^razn* — ► Constraint 

actualized-binding-list : btnding(Id -++ Fa/ue) x list((Id x PaHialLra/ue)) — ► list( (Id x Value)) 
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The following predicates on subtypes define the taxonomy of RM 3.2: 

is-access-to-object-type(State, Subtype) 
is_access_.io_subpro ( gTam_type(5tate, Subtype) 
is^access-type(State, Subtype) 
is-array-type(State, Subtype) 
is~booiean-type(State , Subtype) 
is-by-Copy-type(State , Subtype) 
is-by-referen ce_type( State, Su btype) 
is-ch aracter- type( State, S u b type) 
is-composite-type(State , Subtype) 
is-discrete-type(State , Subtype) 
is-elemen tary_ typ e(State, Subt ype) 
is-enumeration-type(State ) Subtype) 
is-integer-type(State , Su6type) 
is_moduiar_integer_type(5<a^e, Sa&type) 
is_protected_type( State, Subtype) 
is-real-type(State , Sit 6 type) 
is_record_type(State, Su&type) 
is^scaiar_type(State, Su6type) 
is_sign ed_in teger- type( State, Su btype) 
isstring-type(State, Subtype) 
is_tagged_type(State, Subtype) 
is-task-type(State , Subtype) 

Other predicates used in the semantics are 

component-type((Id -++ Value), Type , Id, Su&type) 
convert_return_vaiue(State, View, Subtype, View) 
range~constraints(State , list(Su6type), list(Iian^e)) 
seiect_component_type((Id -++ Value), Record-fields, Id, Subtype) 
subtype-va!ue(State , Subtype, Value) 
test.Jn(State, Value , Su&type) 

type_constraint( Environment, Subtype, Constraint, Type) 

nulL-range(Range) 

incIuded-in(Range, Range) 

vaiues-in-rang^Ranye, set( Value)) 

discrete-range( Range) 

reai_r ange( Range) 

Finally, the following predicates describe state transformers related to various checks and con- 
versions related to subtypes. 

slice-check(State , Range, Range, State) 

view_convert(State, Environment, Subtype, View, View, State) 
subtype-Convert(State, Environment, Subtype, Value, Value, State) 
index-list(State, list( Range), list( Value), list( Value), State) 
return-check(State, Subtype, State) 

4.1.4 Environments and Views 

Environments map identifiers to views. 

type Environment — (Id -h- View) 


38 



An environment is updated using the usual syntax for bindings. 

-[- >->■ -] : Environment x Id x View — ► Environment 

Note that identifiers are assumed to be unique and that all overloading and qualified names have 
been resolved to unique identifiers. 

The lookup of an identifier I in an environment E is written as 

E b lookup / V 

A view describes entities denoted by identifiers as follows; 
type View 

object-view : LValue x Subtype x Object-mode — ♦ View 
loop-view : Id — ► View 
constant-view : Value — ► View 
subtype-view : Subtype— location — *■ View 

subprogram-view : Subprogram-location x (Id A Parameter) x optional(Su6fype) - View 
undefined-view : View 

Object views include a mode description of the form: 

type Object— mode 

variable-object : Object-mode 
cons£anfc_o6ject : Object— mode 
aliased-object : Object-mode 

Whether or not an object may be assigned to depends on its mode: 


assign able( Object-mode) 

Loop views are used in defining exit from named and unnamed loops. 

type Loopld 

unnamed : Loopld 
loop-id : Id — ► Loopld 

The following predicate defines how the bindings of a parameter association are added to an 
environment creating the environment in which a subprogram body is executed. Note that the 
names used in the given parameter association may differ from the names of the formal parameters 
(due to renaming). The names of the formals are provided by a separate argument. 

bind-actuaIs(Environment , (Id View), list(Jd), Environment) 

The following constants of sort Exld denote the language-defined exceptions (others may be 


type Exld 

constraint-error : Exld 
program-error : Exld 
ex-id : Id — + Exld 

New unique names for user-defined exceptions are introduced by static semantics. 
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4.1.5 Memory Model 

run-time values (of sort Value). 
They include type location (see 

type Object-location 

loc : integer — * Object-location 

type Subprogram-location 

type Subtype-location 


Values of sort Store describe the current binding of addresses to Ada 
In our model, there are four different types of addresses (locations), 
above) as well as locations for objects, subprograms and subtypes. 


Object locations are associated only with objects that are not components of other objects. 
Components are specified by the address of the containing object together with a selector sequence. 
An address together with a selector sequence is a L- value (sort LValue). 


type LValue 

location : Object-location — *■ LValue 
array-component : LValue x list (Value) -> LValue 
array-slice : LValue x Range — * LValue 
record-component : LValue x Id ♦ LValue 


Thus, the domain of stores is defined as a 4-tuple as follows: 


type Store 

: (Object-location -++ Value)x 

(Subprogram— location ■+► Subprogram)x 
( Type-location -+* (optional( Type-locatton) x Type))* 
(Subtype-location -++ Subtype) — ► Store 


Individual components of a store can be updated using the following notation: 

_] : Store x Object-location x Value -*■ Store 
_[_ ,_ 2 _] . store x Subprogram-location x Subprogram — ► Store 

( ,3 _] ; Store x Type-location x (optional( Type-location) x Type) -* Store 

J_ _] : Store x Subtype-location x Subtype -* Store 


Values of sort State describe a current store, together with the current status of program execu- 
tion. A state may represent the propagation of an exception, exit from a subprogram, or exit ro 

a loop. 


type State 

exception : Exld x Store — ► State 
exit : Loopld x Store — ► State 
proc-return : Store —► State 
func-return : View x Store — ► State 
normal : Store — ► State 
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The following functions are defined to access and manipulate the store embedded in a state. 

-[- ^1 -] * State x Object-location x Value — ► State 
_[_ 1 f 2 -] * State x Subprogram-location x Subprogram — ► 

-[-^3-] : x Type-location x (optional( Type-foca/ton) x Type) -+ S^e 

-[- * ^4 -] : State x Subtype-location x Subtype — ► State 
- o6j [-] : State x Object-location — ► Value 

■ gtQt € x Subprogram— location — ► Subprogram 
- typ [J\ : State x Type-location — ► (optional( Type_/c>cafi 0 n) x Type) 

— ' 5 ^[-] • iS/a/e x — ► 5wfc^pe 

makestate : Sfa*e x Store — ► State 
thestore : State — + b'fore 

The allocation of new location of the four different kinds is defined by the predicates: 

new_type(State y (optiona\(Type— location) x Type), Type— location, State) 
newsubtype(State ) Subtype , Subtype-location , 5fafe) 
new__object(5fafe, Va/ue, O^ecfw/ocafzon, 5fa/e) 
new_^subpro < grain(5fafe, ^u&proyram, ^^proyram-Zocafion, 5fafe) 

For a given state and L-value, the following predicate defines the current value. The definition 
of this predicate includes access of the appropriate subobjects denoted by an L-value. 

content(State, LValue, Value) 

States are classified as normal or abnormal. Abnormal states will, in general, alter the control 
flow. 

abnormaLstate(State) 

normalstate(State) 

The return from a subprogram may be indicated by an abnormal state. The following predicates 
deal with the cases of procedure and function returns, respectively. 

proc-exit(Staie y State) 
return-value(State, View, State) 

Values stored in the subprogram component of a store are of the form: 
type Subprogram 

subprogram : Environment x list(Id) x Del x Stin — * Subprogram 
operator : Operator — * Subprogram 
unelaborated : Subprogram 

A user-declared subprogram is represented by the declaration environment, the names of the 
formal parameters and the declarations and statements that comprise the body. Predefined operators 
of the language are enumerated by a domain Operator. The definition of the semantics of the 
operators is not covered. An attempt to execute a subprogram of the form unelaborated will raise 
program error. 

4.1.6 Other Predicates 

The following predicates deal with the selection of elements from parameter lists and record com- 
ponent associations. 

the_parameter(list(Pss), Id, Nam) 
gi ven-parameter( 1 ist ( Pss) , Id, Exp ) 
find-component(Id, list(Rca), Exp) 
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4.2 Judgements 

Judgements for various syntactic domains define the effect of the elaboration or execution of language 
phrases of this domain. In most cases, the effect of a phrase depends on the current state and the 
current environment. The effect typically consists of a change in state and the possible return o 
a result. Depending on the kind of phrase, the result may be a value, a type, a new environment 
and so on. The meaning of some phrases depends on additional context beyond the state an t e 
environment. For instance, the meaning of a type definition depends on the discriminant (which is 
part of the enclosing type declaration). 

The general form of a judgement is 

state, environment, context h language-phrase => result, new-state 

The following is a list of the judgements used in the definition. For each syntactic domain, the 
signature of the judgement is given together with an informal rationale. 

If the evaluation of a construct raises an exception then the final state represents this information. 
The propagation of exceptions is described as part of the sequencing of actions described below. 
The following conventions are used throughout the description of judgements: 

51 : State - The initial state. 

E : Environment - The environment. 

5 2 : State - The final state. 


4.2.1 Declarations 

The effect of elaborating a (sequence of) declaration(s) is to add bindings corresponding to the newly 
introduced identifiers to the environment. The elaboration of a declaration may also affect the state. 


Si , Ei b del Del => &2 . S 2 

Ei : Environment - The initial environment 
Q c | ; J Del - A declaration. 

E 2 ; Environment - A possibly modified environment. 

4.2.2 Parameter lists 

Elaboration of subprogram declarations is defined in terms of the judgements 

Si,E,\- P a, Pas => A,S 2 

Pas : Pms* - Formal parameter list. 

A : Id A Parameter - Parameter signature. 


and 

b mod Mod => M 

Mod : Mde - Parameter mode. 

M : Mode - Mode representation. 

The latter judgement uses neither states nor the environment. 
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4.2.3 Type Definitions 

A type definition is elaborated in the context of a (possible) discriminant association. The result 
is the first-named subtype. Elaborating a type definition may affect the state and the environment 
because subexpressions may have side-effects and new internal type names may be bound in the 
environment. 


S u E u D)r tdS Tdf =» T ) E 2) S 2 


D : Discriminant 
Tdf : Tdf 
T : Subtype 
E 2 : Environment 


- The discriminant. 

A type definition. 

- The resulting subtype. 

- The modified environment. 


4.2.4 Variant Parts 

S\ f E t D I - V rn Vrn => V } S 2 

D : Discriminant - A discriminant. 

Vrn : Vnt* - A list of variant clauses. 

V : Variant - The resulting variant. 

The judgement always uses a discriminant that may be empty. 


4.2.5 Discriminant Parts 

The evaluation of a discriminant part results in an association that maps discriminant identifiers 
into their subtype and optional initialization. As with record component lists, the initialization is 
represented by a thunk. 


Si, E \~dsc Dcp => D, S 2 

Dcp : Dcp - A discriminant part. 

D : Discriminant - The resulting association. 

4.2.6 Component Lists 

The result of evaluating a record component list is an association that maps each component identifier 
into a pair consisting of the component’s subtype and an optional initialization. The initialization 
is given by a thunk that represents the initialization expression, together with the environment in 
which this expression is to be evaluated. 


Si j E h cmp Cmp C, S2 

Cmp : Cmp - A component list. 

C : Comp Assoc - The result. 

4.2.7 Subtype Indications 

There are three flavors of judgements dealing with subtype indications. The normal case is covered 
by the declaration: 


S u EV si f Sid => T,5 2 
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Sid : Sid - A subtype indication. 

T : Subtype ~ The denoted subtype. 

A special case is needed for subtype indications that appear inside discriminated records because 
the result will be a partial subtype. 

S u E u DV ps% Sid ^T,E 2 ,S 2 

D : Discriminant - A discriminant. 

Sid : Sid - A subtype indication. 

T : PartiaLsubtype - The denoted partial subtype. 

Finally, a third form of this judgement is needed to deal with access types to allow references to 
incomplete types. Instead of a subtype, this judgement returns a subtype location. 


SuE b sl/; Sid => L % S 2 

Sid : Sid - A subtype indication. 

L : Subtype - A subtype location. 

A completing type declaration will initialize the subtype location. 

4.2.8 Statements 

The execution of a statement only affects the state and has no result. 

Si , E 1 “ stm Stm => S 2 
Stm : Stm - A statement. 


4.2.9 Elsif Clauses 

An elsif-clause consists of a condition and a sequence of statements. The judgement for this construct 
describes the evaluation of the condition followed by the conditional execution of the statements. 
There is a boolean result that indicates whether the condition was true. This result is used in the 
definition of cascaded elsif clauses. 


Si, E \- e if Eif B , S 2 

Eif : Eif - An elsif clause. 

B : Bool - The boolean result. 

4.2.10 Case Alternatives 

The evaluation of a list of case alternatives depends on the value of the case selector: 


S u E,VV clt Alt 5, S 2 


V : Value 
Alt : Alt 
B : Bool 


The value of the case selector. 

A sequence of case alternatives. 

True, if one of the alternatives has matched the case selector. 


The boolean result indicates whether one of the alternatives has been executed. The execution 
of the enclosing case statement will have to terminate in an exception if this result is false. 
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4.2.11 Discrete Choice Lists 


Discrete choice lists are used in variant, array aggregates and case statements. The following judge- 
ment describes the evaluation of a list of choices. The result is a representation of the choices. 

Si, E h C hc Dch => C\ S2 

Dch : Dch* - A discrete choice list. 

C : Choice - The representation of the choice list. 


4.2.12 Expressions 

The evaluation of an expression results in a value and possible side-effects. In certain cases the 
meaning of an expression depends on the expected type (e.g., the evaluation of aggregates and 
string literals). Rather than adding this type information to the judgement, the abstract syntax 
provides such information where necessary. 


S U E \~ exp Exp => V,S 2 

Exp : Exp - An expression. 

V : Value - The resulting value. 

The judgement for conditions differs from that for expressions by returning a truth value. 

SuE\^ e nd Cnd=> K,S 2 

Cnd : Cnd - A condition. 

B : Bool - A truth value. 


4.2.13 Names 

The evaluation of a name results in a view of the named entity. 

Si , E \~nam Nam => W , S 2 
N : Nam - A name. 

W : View - The view denoted by the name. 

The evaluation of certain kinds of names cannot have side-effects (e.g., subtype indications). 
Rather than defining a separate judgement for this case the definition will require that the initial 
and final states are identical in these cases. 

4.2.14 Ranges 

The following judgement defines the evaluation of ranges. In the abstract syntax ranges include 
discrete subtype definitions. The judgement also deals with the definition of the range attribute. 

Si, E \~ rng Rng => R, S 2 

Rng : Rng - A range or discrete subtype definition. 

R : Range - The resulting range value. 
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4.2.15 Record Aggregates 

The following judgement defines the value of a record or extension aggregate. 

Si,E,C\-agg r Agg => V , S 2 

C : CompAssoc - The expected components of the aggregate. 

Agg : Agg - The aggregate. 

V : Id -++ Value - The resulting binding. 

The expected type for the aggregate is provided in the abstract syntax by allowing only qualified 
aggregates. Qualification is added by static analysis where necessary. 

4.2.16 Array Aggregates 

A separate judgement is used for array aggregates. It has an additional sequence of index ranges as 
context. 


S lt E f R t Th aajr Agg=> V y S 2 


R : list(Aan^e) 

T : Subtype 
Agg : Agg 
V : Value - 


The index ranges of the aggregate. 
The type of the elements. 

An array aggregate. 

The array value. 


4.2.17 Attributes 

The following judgement defines the values of (parameterless) attributes as defined in Appendix A 
of the Reference Manual. 

SuE, Wi h att ld=> w 2) s 2 


W 1 

: View - 

A view. 

Id : 

Id 

The attribute name. 

w 2 

: View - 

The view of the attribute. 


All core language-defined attributes are free of side-effects. This means that the final state will 
always equal the initial state. Note that some attributes return a subprogram view which, when 
called, may have a side-effect or raise an exception. But the effect of such calls is not part of 
evaluating the attribute itself. 

In the case of the range attribute, the signature differs as follows: 

Si, E, Wi b attr ran S e => #>^2 

W : View - A view. 

R : Range - A range. 


4.3 Actions 

A sequence of statements is executed by sequentially executing each statement in the sequence. 
Execution is abandoned if one of the statements raises an exception or causes some other change in 
the flow of control. In the case of expressions, the language specifies that, in certain cases, several 
expressions are evaluated in arbitrary order. 
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In order to systematically define different kinds of order of execution of program parts, the notion 
of an action is introduced. An action can be viewed as a representation of a judgement without the 
state. Consider, for instance, the judgement for statements: 


S\,E Stm => S 2 


The corresponding action is a term 


sta.tement-fn(E > Stm) 


that represents the environment and the statement. For convenience, we shall write actions just like 
judgements with the initial and final state omitted. In this case, the action is written as 


E h stm Stm => 

Given an action A, it is meaningful to talk about the effect of executing the action in a given state 
5 q. This is expressed by the predicate run : 


run(5 0 , A, Si) 


holds if and only if the execution of action A in state So results in state S \ . 

Using run it is possible to define different orders of evaluation of sets and sequences of actions. 
The notation 


So 


A\ 




Si 


means that the actions A\ through A n are to be executed sequentially starting in state So and 
leading to Si . The definition of this notation needs to consider the propagation of exceptions by any 
of the actions. 

Similarly, the notation 


So 


A\ 

An 




Si 


means that the actions A x through A„ are to be executed in arbitrary order. 

The set of actions (sort Action) is given by the following terms. There is one action constructor 
for each judgement. 
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type Action 

then : Mst(Action) — ► Action 

new_objectSn : Value x Object-location — ► Action 
at£ribute_/h : Environment x Kieiv x Zd x Kteiv Action 
param_at£ribufce_fn : Environment x Vie to x Id x Value x Kietv — ► Action 
c ase_af tern ati ve_fn : Environment x Ka/ve x AJt x Bool — > Action 
choices_fn : Environment x Dch_/st x Choice — ► Action 
component_/ist_/h : Environmentx 

Discriminantx 

Cmp-lst x 

(Id A (PartiaLsn6tj/j?e x optional( TAwnfc))) — ► Action 
constrain t_fn : Environment x Subtype x Cns x Constraint — ► Action 
compatibie_fn : Environment x Subtype x Constraint — *■ Action 
declaration-fn : Environment x Dei x Environment — + Action 
defauit_vaiue_fh : Environment x Subtype x Koine — ► Action 
discr_assoc_fn : Environment x Subtype x Dca x Constraint — ► Action 
discrimin ant-par t-fn : Environment x Dcp x Discriminant — ► Action 
elsif-dause-fn : Environment x Eif x Eooi — ► Action 
expression-fn : Environment x Exp x Ka/tie — + Action 
n&me_fn : Environment x Nam x View — ► Action 

new_type_fn : (optional( Type_/ocation) x Type) x Type_/ocation — ► Action 
range_fn : Environment x Zing x Range — ► Action 
subfcype_indica£ion_/h : Environment x Sid x Subtype — ► Action 

p_subtype_indication_f/i : Environment x Discriminant x Sid x PartiaLsubtype — + Action 
type_de/inition_fn : Environment x Discriminant x Tdf x Switype x Environment — ► Action 
variant_iist_fn : Environment x Discriminant x Vnfc_/st x Variant — ► Action 
variant-parLJh : Environment x Discriminant x Vrp x optional((Zd x Variant)) — ► Action 
s u b typ e_ c on vertSn : Environment x Subtype x Va/ue x Va/tie — ► Action 
vie w_ con vert _fn : Environment x Su6type x Kiev; x Kietv—*- Action 
content-fn : LValue x Va/tie — ► Action 

assign_fn : Environment x Subtype x XKa/we x Va/ue — ♦ Action 
raw^assign-fn : i Va/ue x Va/ue — ► Action 
finalize-fn : Environment x Subtype x Va/ue — ► Action 
va/ue_sp/iL_fn : Environment x Subtype x Va/ue — ► Action 
discrete^typeSn : Environment x Subtype x Soot — * Action 
covers_fn ; Va/ue x Choice x Bool — ► Action 
statemen£_fn : Environment x Stm — ► Action 
arb-fn : list (Action) — ► Action 

subprogram_body_fn : (Zd A Vie tv) x Vtetv — ► Action 


The following predicates define a sequence of actions for a variety of different syntactic constructs: 

component-actions(Environment , CompAssoc, list(ilca), list((Jd x Value)), list(Action)) 
expression-list(Environment , list(Exp), list( Value), list( Action)) 
index— actions(Environment, list (Sid), (Subtype), list(Acfion)) 
parameter-action(Environment, list(Pss), (Zd x Parameter), (Id x View), Action) 
parameter-iist(Environment } list (Pss), (Id A Parameter), (Zd A Vie to), list( Action)) 
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4.4 State 


Values of sort State describe a current store, together with the current status of program execution. 
A state may represent the propagation of an exception, exit from a subprogram, or exit from a loop. 

4.4.1 Classification of States 

States are classified as normal or abnormal. The following judgements define the classification. 

abnormaLstate{exception(I e , N)) 

abnormaLstate(exit(I s , N)) 

abnormaLstate(proc^return(N)) 

abnormaLstate(func-ieturn( W , N)) 

n orm a Ls t a t e( n ormal( N)) 


4.4.2 Accessing the Store of a State 

The following judgements describe the store associated with different states: 

the_store(exception(I di N)) = N 

thestore(exit(I d , N)) = N 
thestore(proc-ieturn(N )) = N 
thestore(func-return( W, N)) — N 
the^store(normal(N)) = N 

The following judgements describe the construction of states: 

makestate(exception(I d , N), N x ) = exception(I dl N x ) 

makestate(exit(I d , TV), N x ) = exit(I d , N x ) 
makestate(proc—return( TV), N x ) = proc—return(N x ) 
make_state(funcsetum( W , TV), N x ) = func^retum(W , N x ) 
mak&_state(normal(N ), N x ) = norma/(jV 1 ) 
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4.4.3 Reading and Writing the Store 

thestore(S) = (5,?,?,?) 

S otl [I]=B[I] 

the^store(S) = (?,B,?,?) 

S ,pg [I]= B[I] 

thestore(S) = (?,?, 5,?) 

5 typ [/] = B\T] 

thestore(S) = (?,?,?, 5 ) 

S 5tp [/] = B[f] 

Si[I *-*i V] = make-state(Si, thestore(Si)[I *-*i V]) 
5j[/ ( — V"] = makestate(Si , thestore(Si)[I >->2 V]) 
5J/ i — .3 V] = makestate(Si , fche_store(Si)[/ i-»3 V"]) 
Si[I 4 V] = makestate(S\, fche_store(Si)[/ *-*4 V]) 


(Bo, B p , B t , B,)[I t->i V] = (B 0 [/ ^ V], B p , B t ,B s ) 


(B 0 , Bo, Bt, B,)[I t— +2 V] — (Bo, Bo[I l— * V], Bt, B s ) 

(B 0 , B p , Bo, B,)[I t -+3 V] — (B 0 , B p , Bo[I V],B$) 

(B 0 , B p , B t , Bo)[I i-M V] = (B 0 , B p ,B t , B 0 [I ►- V]) 

4 . 4.4 The Content of a Location 

This function differs from storedLvalue because it works on a state rather than a store and because 
it allows L-values rather than just locations. In the case of a structured L-value, the appropriate 
component of a compound object will be returned. 

S b con ten t(location(I)) =S> 

5 h content(L v ) =» array. va/( R S ,B) 

S \- content(anay-component(L v , T,)) => 5[^] 

5 I- contentjLv) => array_vai([.fti], B) 

S h content(array_sIice(I„, il)) => array_vaJ([ R], B) 

S h contentjLv) => record- vai( T,, D Vt CQ 
5 b content(record-Component(L v , Id)) => Ci[/d] 

the_store(S 1 ) = (5,?,?,?) 

- 1 / € dom(B) 

new-object(Si , V,I,Si[I 1 — ►! V]) 
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thestore(Si ) = (?,J,?,?) 
-i/ 6 dom(B ) 


new_subprogram(Si . V, /, Si[7 ► 

-2 Kj) 

the^tore(S 0 [I T e ]) = (?,? 

,5,?) 

-»/ € doni(5) 


new_t 7 pe(S 0 , T e , U,S 0 [I *-3 

rj) 

(he_s(ore(So[/ >-M T e ]) = {?,?. 

,?,B) 

->/ € dom(B) 



new-j}ubtype(S 0 , T e , t/,5o[/i-+4 I'd) • 


4.5 Order of Execution 

4.5.1 Sequential Execution 

SOS 


run(normaI(N) 

•» ^0> $2) 


* ' 



s 2 

. A * 

1 

s 3 





^0 


norma^A^) 



S3 



j 

4* . 



abnormaL^tate{S) 


s 

' At ' 

s 


. A n . 



4.5.2 Arbitrary Order Execution 


S{}S 

abnormaLstate( S ) 



pick(A,Aj,A t ) 
run(normal{N), A,, Si) 



normal( N ) < ... > S 2 
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pick(A ■ A s , A, A s ) 


pick(A t , Ax_, At) 
pick(A ■ A s , A x , A ■ At) 


4.5.3 Executing Individual Actions 

Note that there are predicates that do not involve state. They are included as a matter of conve- 
nience. It is possible to include the appropriate terms in a sequential or arbitrary order execution 
where this makes the definition more readable. 


Si 


Ai 

An 


S 2 


run(Si , then(A), 52) 

new-object(Si , V, L, .S'2) 
run( 5 i , new-objectJfn( V , L), S2 ) 


Si,E, Vb_cit Clt =>• 
run(Si,S, V\- Clt Clt => 0,5a) 

SuE±chc Che => C,S 2 

run(5i , E b c hc Che => C , S 2 ) 

S\,E\- cmp D => Cmp, A 
run(Si , E cmp D => Cmp, S 2 ) 

SuEj \~dci Pci => E 2 ,S 2 

run(5i, E\ b del Del =>■ £ 2 , ^ 2 ) 

Su E H elf Elf => R,S2 
run(5i , E b e \f Elf => R , S 2 ) 

S\ , E \- exp Exp => V,S 2 
run(5i , E I - e xp Exp =>• V, S2) 

Su E l ~ nam Nam =» £>, S 2 
run(5i, E h n( , m Nam => D, S 2 ) 

Su E hrno Rng => 
run(5i 1 E rn g Rng => R , S 2 ) 

SuE b stm Stm => g 2 
run(5i, E b stm Stm =>, S2) 

SuEu_D_ Vjai Tdf =» SuEu^l 
run(Si , E\, D hu/ Tdf =>• St, E2, S2) 

Si , E, St E subtype-convertj V\) => V 2 , ^2 
run(5i ,E,S t \~ su btype_con vert( Vi) => V 2 , S 2 ) 

Si , E, St E subtype-convert ( W\ ) => W2, §2 
run(5i , E,S t h subtype-con vert( W x ) => W2,S 2 ) 
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S I- content(L v ) => V 
run(5,h content(L v ) => V,S) 



subprogram-body(Si W , S 2 ) 
run(5i , subprogram-body _fn( A, W ), 52 ) 


4.6 Values 

4.6.1 Ranges 

discrete-range(discrete-rng(Ii > h)) 
real_range(reaLrng( Ri, R 2 )) 
low-bound(discrete-rng(I , ?)) = discrete— val(I) 


Iow-bound(reaLrng(R, ?)) = real-val(R) 


high-bound(discrete-rng(?, /)) = discretc_val( I ) 
high—boun d( reaLrng ( ? . /{)) = reaLval(R) 
make-range(discrete-val( I x ) , discrete- va/(/ 2 )) = discrete -rngiR , I 2 ) 


make-range(real-val(Ri), reaI-vai(R 2 )) = real-rng(R u R 2 ) 

R X <R 

R ^ R 2 

belongS-to(reai-vai(R) , real-rng(Ri, R 2 )) 

h < I 

/ < h 

belongS-to(discrete-vaI(I), discrete— rng(Ii , I 2 )) 

h > h 

U > h 

included-in(discrete-rng(l l , l-,), discret,e_rng ( / ;J , I 4 )) 

h > h 

nu!Lrange(discrete-rng(/i ,h)) 
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Rx > R? 

null—range(real-rng( R \ , R 2 )) 

values-in-range(discrete-rng(I , /), sefc_of([ discrete_vai(/) ])) 

A > h 

val ues-in—range( discrete-rng( I \ , / 2 ), seL_of([ ])) 

vaiues_iJ3— rang‘e(discrete_rng(A + 1, h), set-of{ V s )) 

vaiues_in_range(discrete_rng(/i , A)) set~.of{discre te_val(/i) ■ V^ s )) 


4.6.2 Index Ranges 

i/idices([ ]) = set-of[[ ]) 

values Jn-range(R, V r ) 
index-pairing( V r , indices^)? V) 
indices(R • i£ s ) = ^ 

index_pairing(set_of([ ]), VA, set_of([ [ ] ])) 

index_pairiflg(set_of( V r )> Vu V x ) 
prefixset-with-element(V , VA, VA) 
inde^.pairing(set_of( V ■ VA), VA, V x U V y ) 

prefix-set-with-element(V , set-of([ ]), set-of[[ ])) 

prefixset—with—element( V , set-p^EV)? set—of[E p )) 

prefixset-with-element( V, set-of(Ei ■ E r ),set-of(V • ■ E p )) 


4.6.3 Predicates of Values 

discrete- vaiue( discrete- val(X )) 


real-value(real-val(X )) 


access_vaiue(access-vai(A' , ?)) 

discrete- value( V") 
scaiar_vaiue( V ) 

real-value( V") 
scaiar_vaiue( 7) 

scaiar_vaiue( V) 
eiementary_v r aiue( V) 
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access^value( V) 
elementary-value( V) 

composite__value(record_va}(X , Y } Z)) 


composite^value(array-val(X , 7)) 

dom( V) — indices(B) 
array^ val u e{ ar r ay_ val( B , 7)) 


4.7 Types 

4.7.1 Type Descriptors 

5 t "p[y] = (? x r„) 

typestruct(S , subtype( \J y ?, ?)) = T y 


4*7.2 Ancestry Relation 


ancestor{S ) U } U) 

S^[U] = (some([/ 2 )x?) 
ancestor^, {^2, t/i) 
a/]cesfcor(5, £/, /7i) 

aflcestor(5, f/ 2 > U\) 
descendants , £/i, f^) 

g*vr[£/] = (ponex?) 
u/fciinate_aflcestor(S, {/, U) 

S^[U] = ( some(U 2 )x ?) 
u/fcjrnafce_a/ices£or(S, £Jj, f/ 2 ) 
uifcirnate_ancesfcor(S, U > U 2 ) 


4.7.3 Ranges of Scalar Types 

base_range(S , enum_type(N)) = discrete.j-ii^O, N) 

base_range(S , /noduiar_fcype( JV)) = discrete-rn^O, TV, — , 1) 
base_range(S, signed Jnteger_type(B f , 5,, ?, ?)) = discrefce-nig^ , £,) 
base_rauge(S, universal-integer^type(Bj , 5/)) = discrefce-jriig( 5/ , 5/) 
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S t = subtype(U } no-Constraint^A) __ 

range_o£jsubtype(S , S t ) = base_range(5\ type^truct(S , S t )) 

range-of-JSubtype(S , subtype( U , range— cons train t( /2) , A)) = B 
ranges_ofljsubf;ypes(5, []) = [] 

ranges-oLj;ubtypes(S , Si • S r ) = range_of_.su btype(S, Si) * ranges_oLsubtypes(S, S r ) 


4.7.4 Values of a Type 

ancestor(5, U , U p ) 

S typ [U p ] = (? X Ty) 

descriptor-vaiue(S, T y , K) 

descriptor_vaiue(S, ciass_type( L), V) 

beiongs-to( K, base_range(S, enum-type(iV))) 
descrip tor_vaiue(S, emim_type(A r ), K) 

descriptor_vaiiie(S, enum_type(iV), invaiicLvai) 

beiongS-to( V , base_range(S, modularity pe(N))) 
descriptor_vaiue(S, moduiar_type(A^), V) 

descriptor— va!ue(S , modular-type(N ) , invaiicLva]) 
descriptor-value(S > signed-integer-type(Bj , Bj, F, b), discrete- vai(iV)) 


descriptor-value(S , signed_integer_type(B/ , B/, B, I), invaiicLva]) 


descriptor_vaiue(S, universai_integer_type(B/, 5/), discrete- vai( N)) 


descriptor- value(S, universal Jnteger-type(Bf , 5/), invaiicLva]) 

arr ay_vaiue(array-va](ranges-of-jsnbtypes(S, /), B)) 

descriptor— vaiue(S, array_type(/, C), array_vai(ranges_of_5ubtypes(5 T /), B)) 

iV e set-o{[adom(D)) 

D[N] = (S t x T fc ) 
subtype-value(S , S t , B[N]) 
discrim in an t_ vai ue( S , discr(B), B) 

discriminant-va!ue(S , D a , D v ) 

ci_vaiue(S, C\, D v , C v ) 

descrip tor_vaiue(S, record-type(T g , B a , Cj), record-val( T g , D v , Cu)) 
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dom(F) = set~ol{adom(A)) 

A[I d \ = (P, x T h ) 

subtype_vaIue(S , actualize(D v , P,), F[Id\) 

varianCvaluesjS , V r , D v , F v ) 

cLvalue(S, fie]ds(A, V r ), D V ,F ® F v ) 

variant-vaIues(S , none, l ) v , [ ] ) 

the_vanant(F, D v [I d ], C t ) 

cLvaluejS, D c , V v ) 

variant^values(S,some((I d x F)),D V , V v ) 


4.7.5 Record Fields 

The following definitions are useful to deal with the types of record fields. Binding B represented 
the values of the discriminants. 


DM = (St X 7jt) 

component_type{B , record-type) T g , discr(D a ), C,), I d , S t ) 

seIect_comp onent-type( B, Ct, I d , S t ) 

component-type) B , record-type) T g , D a , Ct), I d , S t ) 

CM = (A x T k ) 

select-component-type)B , fieIds(C a , ?), h, actua!ize(B, P,)) 

Since component names have to be unique, we can quantify over values V in the following rule. 

the-variant) Vt, V, C \ ) 

select - component -type) B , Ct, I d , S t ) 

select-component-type(B, fields) C a , some((I v x K 6 )>), I d , S t ) 

co vers (A - , C, true) 

the— variant) variant) ( C x Ct) ■ L), X , Ct) 

rovers) X , C, false) 

the_variant(variant(f/), X, Ct) 

the-variant(variant))C x Ct) ■ L),X, Ct) 


4.7.6 Classification of Types 

is_sca/ar_type(g, T v ) 
is-elementary-type)S , T y ) 

is-acc.ess- type(S, T u ) 
is—elemen t ary- type) S ' , T y ) 

is-array-type(S, T y ) 
is-composite-type)S , T y ) 
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is_record_type(5, T y ) 
is-Composite-type(S , T y ) 


is-ta,gged_type(S , T v ) 
is-Composite-type{S , T y ) 

is-protected-type(S , T y ) 
is-Composite-type(S , T y ) 

i s„discrete_type(5, T y ) 
isscalar^type(S , T y ) 

j s-reai-type( 5, T y ) 
is_ J scaiar_fcype(5, T y ) 

is„access_to-,object-type(5 , T y ) 
is_acce5s_type(5 1 T y ) 

is-a,ccess-tosubprogram-type(S , T y ) 

is_access_fcype(5, T y ) 

i s_enujneration-type(5, T y ) 
is-.discrete_type( 5 , T y ) 

isJj3teger_type(5, T y ) 
is_discrete_type(S, T y ) 

type_j?truct(5, T v ) = e^um-type(A^) 
is_enumeration_type(5, T y ) 

is-boolean-type(S } subtype(boolean-tn, ?, ?)) 

is_cfiaracter_type(S, subtype(character_fcn, ?, ?)) 

is-jsigned_integer-type(5, T y ) 
is_jnteger_type(S\ T y ) 

is^noduiarJnteger-type(5, T y ) 
is_ijiteger^type(5, T y ) 

issigned-integer-type(S , subtype(root-integer-tn, ?, ?)) 


type_struct(g, T y ) = modular^type{?) 
is-jnodular^nteger-type(S , T y ) 

not yet defined 
is_reaLiype(5, T y ) 

type-Struct{S, Ty) = access_type(5 t ■ ^m) 
is-a.ccess-to-object~type(S , T y ) 

type-struct(S, T v ) - func_profile(P a , S t ) 
is_access_ to^su bprogram-type( 5 , T y ) 
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type^struct(S , T y ) = proc-profiie(P a ) 
isL_access_to^ubprogram_fcype(S, T y ) 

type.jstruct(S, T y ) — array-type^, B) 
is_array_type(S, T y ) 

not yet defined 
isstring-type(S , T y ) 

type_^struct(5, T y ) = record-type(T y , i?, C) 
is_record_fcype(5, T y ) 

type^struct(5 ) T y ) — record~type(some(It)> D , C) 
is_ f agge d_ ty p e{ 5 , T y ) 

not yet defined 
is~task-type(S, T y ) 

not yet defined 

is-protected_type(S, T y ) 

is-elementary-type(S , T y ) 
is-by-.copy-type(S , T y ) 

is_(:agg > ed_type(5 , T v ) 
is_by_referen ce_type( 5, T y ) 

is~task-type(S , T y ) 
is_by_re/eren ce_type( 5 , T y ) 

is^protected_type(5 1 T y ) 
is_by_reference_type(S, T y ) 


4.8 Subtypes 

4.8.1 Constraint Satisfaction 

satisfies( V r , no-consfcrainfc) 

beiongs-to( V , R) 

satisfies( V y ran ge^cons train t(/2)) 

satisfies(array-vai(B , A ), index_constraint(5)) 


satisfies(record- val( T g , D t R), discnminant-Constraint(D)) 
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4.8.2 Values of a Subtype 


S*n[U] = (P X Ty) 
descriptor-value(S , T y , V) 
satisf\es{ V y C) 

subtype-vaiue(S } subtype(U , C,A), V) 


4.8.3 Actualization 

4.8.3. 1 Values 


ac tualized- val ue( B , p_ val ue( V ) ) = V 
actualized-value(B , discriminant-ref(I)) = B[I] 


4.8.3. 2 Ranges 

actualized-value(B , L) — discrete- vai(Z, a ) 
actualized-value(B , ) = discrete_vai(tf a ) 

actuaHzed-partiaL^range(B , (L x #)) = discreteurng(L a y H a ) 

actualized^range-Iist(B , []) = [] 

actuaiized_raiige_/ist( J 8, i£ • iZ s ) = actualized_partiai_range(5, i£) • actuaiized_raj3ge_iisfc(5, /2 S ) 


4. 8. 3. 3 Binding Lists 

actua/ized_binding_Jist(5, []) = [] 

actualized-binding-list(B , (I x K)-#) = (/ x actuaiized_vaiue(5, K))-actuaiized_binding_iist(.S, /£) 


4. 8.3.4 Constraints 

acfcuaiized_coflstraiji£(i?, p^no-constraint) = no^constraint 
actualized-Constraint(B , p_range_cous train fc(i?)) = range_constraint(actua/ized_parfciai_range(i?, #)) 

actuaiized-.constraint(5, p_Jndex_ constrain t( S)) = index_constraint(actuaiized-range_Jist(i?, 5)) 

C = discriniinant_constraint(actuaiized_bindingJist(i?, 5)) 
actua J /ized_constraint(5, p_discriminant-Constraint(5)) = C 

C — indirect-index-constraint(actuaHzed-range-list(B y S)) 
actuaIized-constraint(B , p-indirect-index-constraint(S)) — C 

C = indirect_discriminant_constraint(actua/ized_binding_iist(i?, 5)) 
actuaiized_constraint(i?, p-indirect_discriminan t-Constraint(S ) ) = C 
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4. 8. 3. 5 Subtypes 


actuaIize(B , psubtype(subtype( U,C,A), P c )) = subtype( U, actualizecLconstraint(B, P c ), A) 


4. 8. 3. 6 Components 


+ A 2 = A\ 4- A 2 

actuaJized-components(B,fieIds(C a ,some(V p ))) = actualized-complist(B , C a )+actualized-variants{B , V p ) 
actualized~components(B , fieIds(C a , none)) = actualized^compIist(B , C a ) 


4. 8. 3. 7 Component Lists 


act unlized_complist( B , [ ]) = [ ] 

actuaIized_complist(B , A) = /4 a 

ac t ualized-complist( B , (/ x P s ) ■ A) - (I x actualize(B, P,)) A a 

the_van'ant( V a , B[I], (7;) 

actuaUzed~variants(B , (I x V a )) = actualized-components(B , C,) 


4.9 Declarations 

4.9.1 Declarations 

4.9.2 Types and Subtypes 

4.9. 2.1 Type Declarations 

The semantics of a type definition are determined in the context of a discriminant association. For 
types without discriminant, this association is empty 


Si,E 1} () \- tdf Tdf => S t ,E 2 ,S 2 

new_subtype(S 2 ,S t ,L s , S3) 

> ^1 1 'del type Ij is Tdf; =>• E 2 [ I d 1 — ► subtypc_view( L s )] , S 3 


Si 

J 

E Dcp => D 

[ E \- td j Tdf => S f , E? 
new_subtype(S 2 ,S t ,L S) S 3 

S 2 

\ 

type 1^ Dcp is Tdf; => E 2 [Id ► subtype^view(L s )] > S 3 


for a given type descriptor, the following rule creates a new unique type name and constructs a 
first subtype. 
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4. 9. 2.2 Subtype Declarations 

A subtype indication may be a named subtype or a subtype with a constraint. In the former case, 
evaluation of the subtype indication cannot have side-effects. 

Si,E f~ nam Nam => subtype-view(I s ), Si 

Si,E H std Nam => S“ p [L s ],Si 

Si,E h nam IMam => subtype-view(L s ), 5 j 
Si,E,Si tp [L s ] h cns Csn =» C, S 2 
compatible(E , Si tp [L a ], C) 

S’ tp [L s ] = subtype) E, Ci,A) 

Si , E h si d Nam Cns => subtype( U ,C, A), S 2 

Si, E hnam Nam =» subtype-View(L,), Si 

Si,E,D b pj , Nam => p-subtype(S; tp [I s ], P-no_constraint), Si 

Si , E b narn Nam =► subtype_view{L,), Si 
p_constnunt(Si , E, D, Sj tp [X ,], Csn, P, S2) 
comp atible{E,S? p [L s ],C) 

S? p [L.] = subtype(U_, Ci,A) 

Si, E, D h p „ Nam Cns => psubtype(subtype( U , no-constraint, A), P),S 2 

The following syntax represents ranges in a discrete subtype definition. It applies only to con 
strained array type definitions. 

not ye t defined 

Si , E Kid Rng => subtype) V, C, A), S 2 

Si, Ei hj.d Sid => S t , S 2 

new— subtype(S 2 , S t , Ls_, S3) 

Si, Ei b r i c i subtype Ij is Sid; => E\ [Id •— * • subtype— view)L s )] , S3 


4.9.3 Objects and Named Numbers 

4.9.3.1 Object Declarations 


Si 

Ei b,id Sid => S t 

new-object-fn(invalicLval, L) 
default-value-fn(Ei, St, V) 
assignSM Ei,S t , location(L), V ) 

s 2 

Si, El b d c i Id : Sid; 

=> E\[Id 1— ► objecfc_view(ioca(:ion(X), S(, variable)], 02 

Si 

Ei b $id Sid ^ St 

new-object-fn(invalicLval, L) 
default- vaIue-fn(Ei, S t , V) 
assign— fn( Ei,S t , location ( L),V) 

s 2 

Si, E\ h dc \ Id : constant Sid; => E x \I d ^ object-view(}ocation(L ) , S u constant)], b 2 

Si 

Ei b 3t d Sid => S t 

new-object-fn(invalicLval, L) 

Ei b eip Exp => V 
assiKn-fn(Ei,S t ,location(L), V) 

s 2 


Si, Ei t ~dd Id : Sid := 


Exp; => Ei[Id object-view(location)L), S t , variable)}, S 2 
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Si 

E\ \~std Sid => S t 
new_object„fn(invalicLval } L) 
Ex Exp => V 

assign~fn(Ei , St, location(L), V) 

5 2 

Si, Ei \-d c i 1^ : constant Si 
Si 

d := Exp; => Ei[I d object-view(h 

E\ l~5jd Sid => S t 
new-object_fn(invalicLval , L) 
defauIt~va!ue-fn(Ei y St> V) 
assignJFn(Ei f St, location(L), V) 

ocation(L), St, constant)], S 2 

s 2 

S\ , Ei h del • aliasec 

l Sid; => E x [I d i-f object-view(location(L), S tl aliased)], S 2 


Si 

Ei h st d Sid => S t 
new_object-fn(invalicLval t L) 
defaulL.valueifn(Ei, S t} V) 
assign-Jn(Ei y S t) location(L) } V) 

S 2 

Su Ei 1 - dc i Ij : aliased constant Sid; => E\[I d object-view(i 

ocation(L), S t , constant)], 5 2 


E\ \~sid Sid => S t 

q n e w_o bjec t_fn ( m vali cL val, L) c 

1:51 E x h e * p Exp =* V 62 

assign-fn(E\,St,loc 3 Ltion{L), V ) 

S\, E\ \-dd : aliased Sid := Exp; => Ei[I d h-+ objects view(Iocation( L)\ S ty aliased)], S2 

E\ Sid ^ St 

q new_ohject-fn(invalicLva}, L) 

1 £1 h exp Exp => V b2 

assign-fn( £) , 5 t , location( L), V) 

Si , Ei h del Ijj : aliased constant Sid := Exp; => Ei[Ij t— > ob ject~view(loc.ation( L) , St, constant)], S2 


4. 9.3. 2 Number Declarations 

Si, Ei \- exp Exp => V, S 2 
new_object(Si , V, L, S 2 ) 

E 3 = E x [Id »-> object_view(location(L), subtype(universal_real-tn, nouconstraint, not_used), constant)] 

Si , Ei h d c i Ij : constant := Exp; =>■ E 3 , S 2 

Si, Ei \- exp Exp=> V,S 2 
new_object(Si , V, L, S 2 ) 

E 3 = Ei [Id h-» object_view(loca.tion(L), subtype(universal_tnteger_tn, no^constraint, not^used), constant)] 

Si, Ei Ij : constant := Exp; => E 3 , S 2 


4.9.4 Derived Types and Classes 

Eq j E\ Sid => subtype(P , C, A) y S\ 

5 : typ [^] = (Pp*T y ) 

new_type(5i, (some(P) x T v ), U ,S 2 ) 

S 0 ,E U Do I - t dj new Sid => subtype( U , C, A), E 2 , S 2 


63 




4.9.5 Scalar Types 


4.9.5. 1 

4. 9. 5. 2 

4. 9. 5. 3 

4. 9.5. 4 


4.9. 5.5 

4. 9. 5. 6 

4. 9. 5. 7 


4. 9. 5. 8 

4. 9. 5. 9 


c i E exp Exp l ^ l 1 c 
Sl l ExpUk 2 r 2 

Si, E \- rn g Exp 1 ..Exp 2 => maJce_range( V u V 2 ), S 2 

Si,S b naro Nam => W,S 2 

abnormaIstate(S 2 ) 

Si, S h rnj Nam' range =>■ fl,S 2 

Si , E \~nam Nam => W, S 2 
normaistate(S 2 ) 

S 2 , S, W Eqtt r range =» R, S 3 
Si , S h rn? Nam' range => S, S3 

not y et defined 

Si, S h rn j Nam'range(Exp) => it, S 2 


Enumeration Types 
Character Types 
Boolean Types 
Integer Types 

Si, Ei h exp Expj => discrete-.val( Vi), Si 
Si, Si E exp Exp 2 => discrete-val(V 2 ), Si 

sw^ypejSy, (some(root__integer_tn) x signed_integer_type( , V 2 , Ft, F2)), ^|S 2 ) 
Si, Ei, {) \~tdf range Expj..Exp 2 => subtype(U , no-constraint, not-used), Ei,S 2 

Si, Ei h eip Exp => discrete-val( V), Si 
new_type(Si,(some(root_integer_tn) x modular_type(V)), U , S 2 ) 

Si,Si,() h t< j/ mod Exp => subtype(U , no-constraint, not-used), E u S 2 


Operations of Discrete Types 
Real Types 
Floating Point Types 

not yet defined 

Si, Ei, D h tdf digits Exp Cns => S t ,E 2 , S 2 

not yet defined 

Si , Si , D h t d/ digits Exp => S t , S 2 , S 2 

Operations of Floating Point Types 
Fixed Point Types 

not yet denned 

Si, Ei, D \~tdf delta Exp digits Exp Cns => S t , S 2 , S 2 

not yet defined 

Si, Si, D \~tdj delta Exp digits Exp => S t , S 2 , S 2 
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not yet defined 

Su Ei, D h td j delta Exp Rng => S t , E 2 , S2 


4.9.5.10 Operations of Fixed Point Types 

4.9.6 Array Types 

The evaluation of a subtype mark has no side-effect. Therefore, the evaluation of lists of subtype 
marks is defined sequentially. 


S,E\-sti ()=»[] 


S, E h nam NamQ => subtype^view(L $ ), S 

5, E h sti (Nam, ...)=» S t 

Si E hsti (Nam 0 , Nam, ...)=> S st *>[L s ] • S t 

index-actions(Ey (),[],[]) 


index-actions(E , (Sid, . . .), S t ,A c ) 

index~actions(E , (Sid 0 , Sid, . . .), Sto ■ S t ,E \- std Sidg => Sto • A c ) 

range_constraints(S , [],[]) 


type-constraints(S t S ti R) 


range__constraints(£\ subtype(?, range-Constraint(Ro), ?) - St,Ro - R) 

not yet defined 

Si, Ei t D h t df array ( Rng Jst)of aliased Sid => S t , £ 2 , S 2 

not yet defined 

Sit Ei, D \- t dj array(Namg, Nam, . . .)of aliased Sid => S t , E 2 , S 2 


index-actions(E , Idx, S ty A c ) 
Ei Sid => S t 
Ac 1 


Si 


S 2 


range-constraints(S 2 , S t , R) 
new_type(S 2) (none x array_type(Sj, S t ))> U,Sz) 


S\, Ex, {) I ~tdj array(ldx)of Sid => subtype( U , index-constraint(R), not-used), E 2} S3 


Si , Ei h su Idx =>• Si 
Si, Ei \- std Sid => S t , S 2 

new_type(S 2 , ( none x array_type(S t , S t )), U, S 3 ) 

S\ , E\, () F tdj array(ldx)of Sid => subtype(U , no-constraint, not^used), E\ , S 3 
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Si, E, D h„ rn when Dch => CmpVrp; Vnt; . . . => variant((C„ x fields(C, K)) • B 2 ), S2 
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4.9.9 Tagged Types and Type Extensions 

4.9.9 . 1 Type Extensions 


Si 


So , Pi h aid Sid => subtype(P, C, A ), Si 
5j yp [P] = ( P p x record-type(some{Up) 1 D\ ) fields(Ci ) V^))) 

E\ cmp D 0 Cmp 
El , Do I “vrn Vrp => V 2 

new_type_fji((some( <7 P ) x record-type(some( U), discriminant-union(Do, Di), fieIds(C\ 0 C 2 , V\ 0 ^ 2 )))» U) 
So, E\, Do \~tdf new Sid with Cmp => subtype( [7, no-constraint, not— used), P 2 , S 2 


none® K = V 
V 0 none = K 


discriniinanL_union(c/iscr(^4 1 ), discr(i4 2 )) = discr( j4i ® A 2 ) 


4.9.10 Access Types 


Si, E\ 1 ~sid i Sid => L s ,S 2 

new~type(S 2 ,(none x access-Jype(Z,, pool -access)), U , S 3 ) 

Si , Pi, D h tdf access Sid =>* subiype( U , no^constradnt, not-used), E\ , 53 


Si, £1 ^Std* Sid =► Z,,S 2 

new~type(S 2 j (none x access, type(L s , g//_access)), U , S 3 ) 

Si, Ei, D h tdf access all Sid => subtype(U , no-constraint, noi-used ), E\ , 53 

S\ y El hs,d t Sid => L s , 5 2 

new_f;ype(S 2 , (none x access_iype(Zj , cons/ant_access)), f7, 53 ) 
5^7^T tdf access constant Sid =>- subtype(U , no-constraint, not-U$ed ), Pi, 53 


5i , E h pa , Pms => >1, 5 2 

5i 5 P,(> h t d/ access procedure Pms => subtype( {7, no_consfcraint, not-used ), P, 5 2 [proc_pro/ile(y4) (/] 


Si, E \-p Q s Pms ^ X, 5 2 

5 2 , E h nom Nam =» subtype, riew(5/), 5 2 

5i , Pi, () \~tdf access function Pms => subtype(U , no-constraint, not-used), P 2 , 5 2 [funcL-pro/jle(.4, S^fSj]) •—►3 U] 


4.9.10.1 Incomplete Type Declarations 

In the case of access type definitions, a subtype indication may denote an incomplete type. 

Si, P Pnom Mam => subtype^view(Ls), S\ 

Si, E h sid % Mam L s ,Si 


Si y E h nam Nam => subtype-view(L s ), 5i 
Si, P, Sj £p [P,] Peru Csn => C, S 2 
compatib/e(P, S/^fZ,], C) 

S? tp [L 3 } = subtype(U ) C u A) 
new^subtype(S2 , subtype( U, C , A), L t , S3) 
Si, E I ~std, Nam Cns => L t , S 3 
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() = discr([}) 

For incomplete type declarations, a new incomplete type descriptor carries the discriminant infor- 
mation. 


new_type(So, (none x inco/npJefce_iype(())), U,S\) 
new-jsubtype(S\ , subtype(U , no-constraint, not-used ), L s , S2) 
So, Ei b dci type l d ; => Ei[I d t-> subtype_view(Z. 5 )], S 2 

Si, Ei b dsc Dcp D,S 2 

new_type(S2, ( none x incomplete-type(D)), U, S3) 
new^ubtype(S3, subtype) U, no-xonstrajnt, not -used), L s , S4 ) 
5i.Fi \~dci type l d Dcp; => £i[/ d subtype_view(I 5 )], S 3 

Completing type declarations have their own abstract syntax. 


El \~iookup Id => subtype-view{L,) 

Si, Ei, () \- t df Tdf => S t , E'i, S 2 

Si, Ei b del completetype Id is Tdf; =$• E 2 , S2[T 5 1 — ^4 5 «] 


Ei b lookup U => subtype-view(L,) 

Si 

E b dsc Dcp =>■ D 
E,D\- tdf Tdf ^S t ,E 2 

s 2 

Si, Ei b dd compj 

ietetype Dcp is Tdf; => E2,S2[L$ n-b 4 St] 


4.10 Expressions 

4.10.1 Names 

E bj ookup Idn => W 
S, E b nom Idn => W,S 


E b„ orn Nam =>• object-view(Li, S tl ?) 
b contentful ) => access_val( W ,?) 

Si , E b„ om Nam. all => W , S 2 


4.10.1.1 Indexed Components 

The function expressionJist computes a sequence of actions that corresponds to the evaluation of a 
sequence of expressions. 

expression-list(E , [],[],[]) 


expression~list(E , Exs, V S) A s ) 

A = E h exp Exp => v 

expression-list(E , Exp ■ Exs, V • V s , A • A s ) 

index-list(S , [],[],[], S) 
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4.10.1.2 


beio/igs_to( V y R ) 

indexJtist(Siy R s , V 3 yI 3 yS 2 ) 

index_/ist(5!, R 72,, V • V 3 , V * I 3) S 2 ) 

"i beIongS-to( V , R) 

index—list(normal(N) , R ‘ R S} V ■ V 3 , 1 • I 3l exception(constraint-error , N)) 


Si< 


expression-! ist(E , Exs, K*, A 3 ) 

[ E h nam Prefix object- view( L \ , 5 t , ?) 


5 2 


^*n 

abnorji)al_state(5 2 ) 


SlyE hnam Prefix(Exs, ...)=> undefined, view, S 2 

expression-list(E y Exs, V t > A 3 ) 

E \~nam Prefix => objecfc_vieiv(Ii, S t > C) 'J 


5i 


>52 


n orm aLs t a te( S 2 ) 

type_3truct(S2, St) — array_type(? , 5) 
S 2 h content^) array_va](72, A v ) 
indexJist(S 2 , 72, V t) 4, S 3 ) 


S \ , E h nam Prefix(Exs, ...)=> object-.view(array_component(bi, /*), By C), S 3 


Slices 

nuiLxange(72,) 

s7ice-cbeclc(S, R S y R a , 5) 

inciuded_in(72 5 ) 72 a ) 
siice_c7iedc(S, 72,, 72 a , S) 

-«nu]Lrange(72,) 

->inciuded_jn(72,, R a ) 

sJice_cbecJt(norma/(A r ), R S} R a exception(constraint-errory N)) 

n l E h nam Prefix => W 1 „ 

E t- rng Rng => R s J° 2 

abn o rmaL_state(5 2 ) 

S\, E hnam Prefix(Rng) => undefined- view, S 2 

Q f E h n a m Prefix object-view(L v , S t > C) 1 ^ 
£h rn ,Rng=>^ / 2 

norm aLsta te( 5 2 ) 

S 2 h content^) => array_vai([ 72 a ], j 4 v ) 
constrain( 5 t, range_constraint(72 s ), S^) 

siice_cbedc( 52 , 72,, 72 a , S3) 

Si , E h nam Prefix(Rng) => object_vjew(array-j5iice(L v , R s )y S qi C), S 3 
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4.10.1.3 Selected Components 


SuE b narn Nam =» W , S 2 
a bn orm al^sta te( S 2 ) 

5i, E b nam Nam.ldn => un defined- vie w, S 2 

Si,E b nam Nam => object- view( L V} S t) ?), 52 
component-type(D v , type_sfcruci(52, 5*), Idn, 5^) 

52 b con ten t(L v ) => record-va!( T gi D v , C v ) 
jiew_object( 52 , A, [Idn], L , 53 ) 

5i, 2? b nam Nam.ldn => object- view(Iocation(L), 5 g , constant ), 53 

5i, £ b nam Nam => object-view(L v , S tt C), 52 
52 b content (1^) => records vai( T g , C„) 

compojient_type(I) t ;, type_jstruct(52 > 5e), Idn, 5 g ) 

S\ , E b nam Nam.ldn =>• object- vie w(record-Component(L v , Idn), 5 9 ,C), 52 

5, £ b nam Nam object_view(I|;, 5*, ?), normai(A^) 

->component-type(B , fcype-jstruc^norma^lV), 5t), Idn, 5 g ) 

5, E b nam Nam.ldn => undefined- view, exception(consfcrainfc_ermr, jV) 


4.10.1.4 Expanded Names 

4.10.1.5 Attributes 


0 

E b nam Nam W\ 

a 

*->1 

E, W x h oM Idn => W 

*- , 2 


Si 


S\,E b nam Nam'ldn => W~ S 2 

5i, E b exp Exp => V, 5i 
E b nam Nam => VTi 
E f W U V b^ldn^ ^ 


5, 1 b„ am Nam'ldn(Exp) =» W, 5 

Note that the abstract syntax distinguishes N’I(E) for static expression E from N’I(E) where N’l 
is a function-valued attribute. 


4.10.2 Literals 


5, E b exp null => null, 5 

In the abstract syntax, the representation of character literals is given by the numeric value of the 
position of the character. 


5, E b exp 'C => discrefce_val(C), S 
5, E \~ exp R => real_val(i2), 5 
5, E \- eX p N => discrete-va^N), 5 
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4-10.3 Aggregates 

Only explicitly qualified aggregates are defined. Static semantics adds qualification where needed. 

We assume a normalized representation using named associations. This is possible because of 
[ 4 . 3 . 1 ( 14 )]. 

Si,E\~ nam Nam => subtype^view(L 3 ), S\ 
typestruc^Si, S[ tp [L s ]) = record-type(T g , discr(L), Cj) 

5i 5£p [Zj] = subtype (? , no-constraint,?) 

S\ t E,L\- a gg Agg => B d , 5 2 

ff 2 , E, actuaiizecLcomponents(B d , Q) h agg Agg => B c , S 3 
S\, E P eX p N a nr/ Agg => record-val(T g , B d , B c ), S 3 

•Si, E \~nam Nam => subtype-view(L s ), S\ 
typestruct(Si, Sl tp [L s ]) = record-type(T g , D a , Ci) 

S* tp [L $ ] = subtype(? , discriminant-constraint(B d ),?) 

Su E, actualizecLcoinponents(B d , Ci) 1 - agg Agg => B c , S 2 
Si , £ Nam'Agg => record- vaf(T g ,B d , B c ), 5 2 

/incL-componen^/d, others => Exp ■ Rea, Exp) 


member{I d , Lst) 

find-component{I d) Lst, . . . => Exp • Rea, Exp) 

component-actions(E , [ ], Rea, [],[]) 


find^.component(I d , Rea, Exp) 

component_actions(£, ,5, Rea, B Ci A s ) 

componen fc_ac tions( E , (/<*x?) 5, Rea, (I d x K) • £ c , E h exp Exp => V A s ) 

->find-component(I dl Rea, ?) 

component-actions(E , B , Rea, B c , ^4 5 ) 

component_actions(£ , J (/^x?) • B, Rea, (I d x V) • B C) h cxp Exp =» V >1,) 


component~actions(E , v4, Rea, B, >1,) 

. 

Si 

Si , E, A \~ agg (Rea, ...)=>- B, S 2 



5, £, [ ] h api7 (null record) => [ ], 5 


not yet defined 


S U E, C s \~ agg (Expi, Expj, ...)=> V", S 2 

not yet defined 

Sh E , B SJ C, (Exp 1? Exp2, . . . , others => Exp) => V , S 2 

not yet defined 

S \ , E , R s , C$ b a gg ( Aca i , Aca 2 , ■ • •) ^ V , S2 

not yet defined 

Si,E, R s , C, (Expj, Exp2, . . ., others => Exp) => V , S 2 
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4.10.4 Operators and Expression Evaluation 

It is assumed that static semantics has resolved all operators into function calls as defined in [4.5] 
with the following exceptions: 

• short-circuit operators 

• in and not in operators 


4.10.4.1 


Logical Operators and Short-circuit Control Forms 


„ [ E h exp Expi => discrete-val(l) 

^ | E Exp? => V 

Si, E \~eip Expj and then Exp 2 => 


5 2 

V,S 2 


Si,E \~exp Expi =» discrete_va/(0), S 2 

Si, E h erp Exp! and then Exp2 => discrete-val(0), S 2 

[ E h exp Expi => discrete- vai(O) 1 „ 

5l 1 E hexp Exp ? => V 1 2 

Si ,E\- exp Expi or else Exp2 => V, S 2 

Si , E h eip Expi => discrete-val( 1 ) , S 2 

Si, E \- exp Expj or else Exp 2 => discrete-val(l) , S 2 


4.10.4.2 Relational Operators and Membership Tests 

Si, E hnam Nam =$> subtype-view(Ls), Si 
Si,E\- eX p Exp =>■ V,S 2 

belongS-to( V, range-ofLsubtypejSu Sf tp [L s ])) 
Si, E h exp Exp in Nam => discrete-vaJ(l) , S 2 


Si , E h„am Nam => subtype-view(L,), Si 
Si,E\~ exp Exp => V , S 2 

-ibelongs_to( V_, range-ofs ubtype(S 2 , S‘ tp [L,])) 
Si, E h exp Exp in Nam => discrete_val(0), S 2 


O f E h mg Rng =>■ S. \ n 
Sl \ E K X p Exp => V r 2 

belongs-to( V , R ) 

Si, E VZp Exp in Rng =$> discrete-val(l), S 2 


Si 


Si, E h exp 


( E h rng Rng R 1 n 
{ E h exp Exp => V J° 2 

->belongs-to{ V, R) 

Exp in Rng => discrete-val(O), S 2 


-<is-tagged-type(S, S t ) 
S t = subtype(U, C ,?) 
satisfies] V , C) 
test-in(S, V,Si) 
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S t = subtype( U , C, ?) 
safcisiies( K, C) 

V = record- val(some( T g ), ?, ?) 

ancestor(ff, [/, T g ) 

test-in(S, V.St) 

Si } E h nam Nam subtype-view(L s ), 5i 
5ii E \~exp Exp => K,5 2 

tesUnjS^ K, 5j ,tp [I,]) 

5*1, E \~ exp Exp in Nam => discrete-. va/(l), S 2 

Si, £ h nam Nam =» subtype-view^Z*), Si 
Si, Eh exp Exp => V } S 2 

-itesUnjSj, V,S, ,tp [L s ]) 

Si, E exp Exp in Nam => discrete_vai(0), S 2 

SuE\- exp Exp in Nam => discrete -val(l) y S 2 
S\ , E h exp Exp not in Nam => discrete_vai(0), S 2 

Siy E \- exp Exp in Nam :=> discrete_vai(0), S 2 
S\y E \~exp Exp not in Nam => discrete_vai(l), S 2 

Siy E h exp Exp in Rng => discrete-.vaJ(l), S 2 
Si , E \~ exp Exp not in Rng => discrete- va/(0), S 2 

Siy E hexp Exp in Rng => discrete- vai(O), S 2 
Siy E h exp Exp not in Rng => discrete_vai(l), S 2 

Siy E \- exp Exp in Nam => discrete- vai( 1 ), S 2 
Su E exp Exp not in Nam => discrete„vai(0), S 2 

Si, E h exp Exp in Nam => discrete- va/(Q), S 2 
Siy E \- eX p Exp not in Nam => discrete_vai(l), S 2 


4.10,5 Type Conversions 

Si, E f- nam Nam => subtype-view(L s ) y Si 
n E exp Exp => Vi 

1 E y S* tp [L s ] h subtype-Convert( Vi) => V 2 
Siy E h exp Nam(Exp) => V 2i S 2 


S 1, E \- nam Namj => subtype-view(L s ), Si 
E I - nam Nam 2 => Wi 

E, S* tp [L s ] h subtype-Convert( Wi) => W 2 
S\ y E h nam Nam 1 (Nam 2 ) => W 2 , S 2 
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4.10.6 Qualified Expressions 


Si, £ E nam Nam => subtype-view(L s ), Si 
Si , £ h exp Exp =>■ V , S2 

abnormaLstate(S2) 

Si,£E eip Nam'(Exp) =► V,S 2 

Si , E \~nam Nam => subtype-view(Ls), Si 
S**[L»\ = subtype(?, C,?) 

Si,E \- exp Exp => V,S 2 
norm aLjstate(S 2 ) 

satisfies) V , C ) 

Si,E\- e xp Nam'(Exp) =» K,S 2 

Si,E E nom Nam =► subtype_view(Z s ), Si 
5 1 5tp [I J ] = subtype( ?, C,?) 

Si , £ E exp Exp => V , normal(N) 

-isatis/?es( V, (7) 

Si, £ h exp Nam'(Exp) => 7 , exception(constrain terror, N) 


4.10.7 Allocators 


_ £ E exp Exp V £ 

1 new~objectlfn(invahd-val, L) 2 

Si, £ E exp new Exp => access-val(object-view(location(L),?, aliased), none), S 2 


not yet defined 
S, E Kxp new Sid => V , S 


4.11 Statements 


4.11.1 Statement Sequences 


So 

5 ^£ 


£ E stm Stm^ ^ ^ 

£ bjtm Stm? ■ ■ ■ =» 1 1 
Ejtm Stmj Stm2 ...=> Si 


S,E\- stm ()=>£ 


S, £ E, tm Stm => S 

5, £ E stm « Nam >> Stm => S 

S, E E, trn null; => S 
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4.11.2 


4.11.3 


Assignment Statements 

assignable variable) 

assign a We( aliased ) 


sJ 

E 1 ~nam Nam => object-view(L } S ti M) 

u 


E 1- exp Exp => V 

assignable(M) 

r 1 


E, S t H subtype-convert( V) Vi 

h content(L) => Vo 


Sl 

finalize-fn(E, St, Vo) 
assign-fn(E , S t) L , Kj) 
vaiue_spiit_Jh(J5’, V"i) 

5 2 


& r stm Nam := txp => b 2 

Q \ E h nam Nam => object-view(L } St , variable) \ c 
*1 E h„E«p=»V / Sl 

not yet defined 

So, E l"»tm Nam := Exp => Si 


If Statements 


Si 


E h 


exp Exp 

EY- 


stm 


discrete- val(l) 
St m j^=> 


S 2 


$ 1 , E I - stm if Exp then Stm^ Eif else Stm2 end if; =$► S 2 


Si 


E b- txp Exp => discrete_vai(0) 
E h eij Eif =$> true 


S i, E if Exp then Stm^ Eif else Stm 2 end if; => S 2 


Si 

E h exp Exp => discrete_vai(0) 
E he// Eif => faise 
£ h 3 tm Stmj =£■ 

s 2 

Sl , £ if 

Si 

Exp then Stm^ Eif else Strri 2 end if; ^ S 2 

E I ~ ex p Exp => discrete_vaJ(l) 1 ~ 

E h, fm Stmi => j ^ 

s 1,E\- 

S i 

5tm if Exp then Stmj Eif end if 

E \~exp Exp => discrete_vai(0) 

E h e if Eif => true 

=> S 2 
S 2 

Si,E\- 

S i 

if Exp then Stmj Eif end if 

E \~exp Exp => discrete- vai(0) 

E eif Eif => false 

=> S 2 

s 2 

Si, E h s t m if Exp then Stm^ Eif end if; => S 2 


S, E \~ e if () => false, S 


Si, E h e if Eif ^ => true, S 2 
S x , E h t if Eif ^ Eif 2 . . . => true, S 2 
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Si 

E b eif Eif 1 => false 
E b eJ f Eif 2 • • ■ => R 

s 2 

Si,, 

E b e if Eif^ Eif2 . . . => Ry S 2 


c 

E b elp Exp => discrete-val(l) 

59 

Z>1 

E b Jtm Stm => 

u A 


Si } E b ei j elsif Exp then Stm => true, S 2 


Sly E b exp Exp => discrete^vai(Q), 5 2 
Siy E b eif elsif Exp then Stm => false, 5 2 


S U E 


Si 

b stm 


E b exp Exp V n 

E, V b c / t Alt => true 2 __ 

case Exp is Alt end case; 


=► 5 2 


4.11.4 Case Statements 

normal(N), E, V \~ c it {) => R, exception(constraint-error, N) 


Si,E, V Kit Alt! => true, 52 
Si) E, V I - c it Altj Alt2 - ■ ■ — ^ true, S 2 


Si 

E, V b dt Altj => false 
E,V b elt Alt, ...=> R 

S 2 

Si,E, V\- cU Alt x Alt 2 ...=> R,S 2 

Si 

E b chc Dch =>■ C 
covers— fn( V , C , true) 
E b 3fm Stm => 

5 2 

Siy Ey V \- c it when Dch => Stm true, 5 2 

Si 

E b c hc Dch => C 
covers-fn( VyCy false) 

S 2 


Si,E,V \- clt when Dch => Stm => false, S 2 


S , E h,(m Stm =» exit( unnamed, N) 

S, E hjtm loop Stm end loop; => normal(N) 


4.11.4.1 Choices 

Si , E b rn g Rng ^ it, 5 2 

S, E b c hc Rng => choice-range(R), S 2 

Si,E beip Exp =» V ,S 2 

Si ,E\- C hc Exp => choice- vaJue( V),S 2 

S,E \- c hc others => choice-default, S 
S, E b c hc (> => ciioiceJst([ ]),S 


Si ,E\~ c hc Dch^ => Ci,S 2 
S 2 ,£ b c h c Dch 2 I ■ • • =» choice-ist(C2), S3 
Si,E b chc: Dchj | Dch 2 | . . - =>• choiceJst(Ci ■ C 2 ), S 3 
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covers( V, choice-value( V ), true) 


Nx±N2 



Si, E\ h ,tm Idn : while Exp loop Stm end loop; => normal(N) 
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unique(X) 

Si, £i[ldn h-» loop-view(X)] E 5tm while Exp loop Stm end loop; exit(IoopJ[d(X ) , N) 
Si, Ei h st m Idn : while Exp loop Stm end loop; => normal(N) 


4.11.6 Block Statements 


Si ) E H Hsm = r y S 2 
Si , E \~ stm begin Hsm end; => S 2 


Si,E \~ stm Hsm => S 2 

Si, E h Jtm Nam : begin Hsm end; => S 2 


Si 


E x \- dcl Dct E 2 
E 2 h stm Hsm => 
S 2 ,E 2 \~ finalize(B) => 


S 2 

S3 


Si, Ei h s tm declare Del begin Hsm end; => S3 


Si 


Ei h del Del => E 2 
E 2 V s tm Hsm => 
S2 ) E 2 h finalize(B) => 


S 2 

S 3 


Si, Ei E Jfm Nam : declare Del begin Hsm end; => S 3 


4.11.7 Exit Statements 

normal^), E b 5fm exit; => exit( unnamed, N) 


S , £ h nQm Nam => loop-view(X) y normal(N) 

S, £ exit Nam; => exit(Joop_id(X), N) 

S, E \- exp Exp => discrete-val(l ) , normai(TV) 

S, E exit when Exp; => exit( unnamed, N) 

Si, E \- €Xp Exp =» B y S 2 

Si, E h 3fm exit when Exp; => S 2 


5 

E E nam Nam => ioop_view(X) 
E h ejcp Exp => discrete^ val(l) 

normal(N) 

S, # exit Nam when Exp; => exiti 

(loop-id(X), N) 


Si 


E K 


Nam 


E \~ exp Exp => 


> ioop_view(X) 
discrete- vai( 0 ) 


S 2 


Si, E h stm exit Nam when Exp; => S 2 
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4.12 Subprograms 

4.12.1 Subprogram Declarations 

Si , Ei b pas Pms => A, S2 

new_subprogram(S2 , unelaborated , < 7 , £3) 

S\ y E\ h dd procedure Idn Pms; =j> E\ [idn 1— * subprogram-view( U , A, Done)], S3 

Sly El h pas Pms => A, S 2 
S 2) P„am Nam => subtype^view(Si ), S 2 

new^subprogram(S2y unelaborated , ( 7 , S3) 

^1 del function Idn Pms; => £i[ldn 1— ► subprogram- vie w( £/, ^ 4 , som eiS> tp [S,}))},S 3 

S\yE h pas Pms => Ay S 2 

E h lookup Idn subprogranrL-view( U y A y none) 

Su E h procedure Idn Pms is Del begin Stm end; => E y S 2 [U »— b 2 subprogram(E , adom(A), Del, Stm)] 

S\y E h pas Pms => 4 ,S 2 
S 2 , E \- nam Nam => subtype~view(Si)y S 2 
E h lookup Idn => subprogram-view(E7,>l,some(S2 5 * p [S/])) 

S\y E h del function Idn Pms is Del begin Stm end; => E } S 2 

SyE h pas <) =>[],5 

not yet defined 

S, E h pas Idn : access Nam; Pms; . . . => A, S 

not yet defined 

Sy E h pas Idn : access Nam := Exp; Pms; . . . => A, S 

\~mod Mde => M 

S\ , E \- na m Nam => subtype_view(Si) } S x 

___ S \ , E l~ P d$ Pms, . . . A \ y S 2 

S\>E\- pa$ Idn : Mde Nam := Exp; Pms; . . . => A \ [Idn forrnai(Af, S( P [S/], some(thunk(E y Exp)))], S 2 

\~mod Mde => M 

S\y E \~ nam Nam => subtype-view(St), S x 

S\ 1 E h pas Pms; . . . A x , S 2 

Sy E \~ pas Idn : Mde Nam; Pms; . . . => Ay S 


4.12.2 Formal Parameter Modes 


\~mod in => in^mode 


\~mod in out => ni-out^mode 


P mod in-mode 


I ~mod out => out_mode 
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4.12.3 Subprogram Bodies 

There are no semantics associated with subprogram bodies. The declarations and the statement 
part of a subprogram body, together with the declaration environment, are stored as a subprogram 
value. The rules given below define the effect of executing a subprogram value. 

The following definition creates an environment for the execution of a procedure body by binding 
the formal parameter names to the views of the actual parameters. The actual parameters are given 
as an association but, due to renaming, the names in the association may differ from those of the 
formal parameters. 


bind~actuals(E , [],[],£) 


bjnd_actuais(Ei [I\ ► W{\ y P, Ids, £3) 

bind-actuals(Ei, (P\ x W\) • P ) I\ * Ids, £3) 

proc-exit(exception(X , N) i exception(X , N)) 

not yet defined 
proc-exit(exit (? , N), ?) 

not yet defined 

proc_exit(func_returj2(?, N), ?) 

proc-exi t(procu:et urn( N ) , normal( N )) 


proc~exit( n ormal( N ) , normal(N)) 


S* P 9 [L] = subprogram(E\ , Ids, Del, Stm) 
bind-actuals(Ei , A, Ids, E 2 ) 

E 2 Del => E 3 
E 3 \~ 3 tm Stm => 
proc-exit(S 2 , S3) 


Si 


S 2 


subprogram-body(Si , A , subprogram-view(L y A/, none), S3) 
return_cbedf(excepfcion(A r , N) } St, exception(X , N)) 


not yet defined 

return-check(exit(? , N) : S ( , S) 
not yet defined 

refcurn_checic(proc_refcurn(AT)i S t , S) 

convert-return-value(normal(N ), W\,S t , W 2 ) 

return-check(func-return( W U N ), S t , func-return( W 2 , N)) 

return~-check(normal(N)> S u exception(program-error, N)) 
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S( pg m — subprogra,m(Ei , Ids, Del, Stm) 
bind-actuals(E\ , A, Ids, £2) 

E2 \~dci Del ==> £3 
E3 I” stm Stm 
Teturn„check(S2 , St, S3) 


Si 


S 2 


subprogram-body(S\ , A , subpro < gram_view(L 1 A/, some(St)), 53) 
Appropriate rules need to be defined for all predefined operators. 


S* P9 [L] = operator(Opn) 
not yet defined 


subprogram-body(S\ , A, subprogram-view(L ) A/, ?), S2) 
A call to an unelaborated subprogram raises program error. 


normal(N) sp9 [L] — unelaborated 

subprogram~body(normal(N ) , A, subprogram-view(L, ?), exception(program-.error , N)) 


4.12.4 Subprogram Calls 

The rules given here are incomplete and do not describe subtype and view conversions that are part 
of a call. 

return_vafue(func_refcurn( W, N), IT, normai(A)) 
return-value(exception(X , N ),?, except ion( X , N)) 

parameter_fis£( E , Pss, Aj , A a , P) 

W — subprogram- vie w(?, A/, ?) 


Si 


■ 

E H nam Nam =>• W 


< 

P 1 





_ subprogram_body_fn(A a , 

W) 


S2 


return_vaiue(.$2> JT r , £3) 


Si, E h nam Nam(Pss, ...)=> lT r , S 3 

parameter__/ist( £ , Pss, A/ , A a , P) 
W = subprogram-view(? y Aj ,?) 


Si 


" 

E h nom Nam => W 


< 

P 1 

> 




sub p r ogr am_ b 0 dy_fh ( A a , 

W) _ 


S2 


Si, £ Ktrn Nam(Pss, .. .); => S 2 
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4.12.4.1 Parameter Associations 


parameter-Iist(E , Pss, [],[],[]) 


parameter-Iist(E, Pss, F, R, A) 
parameter-action(E , Pss, F x , Ri,A\) 
parameter-iist(E , Pss, F\ • F, Ri ■ R , A x ■ A) 

-»gi ren_parame ter( Pss, Idn, ?) 

parameter-action^, Pss, (Idn x formal(in-mode, S t , some(thunk( E x , Exp)))), (Id n x constant. vie w( 1/)), h e:rp Exp 
given-parameter (Pss, Idn, Exp) 

parameter-action(E , Pss, (Idn x for mal(m -mode, S t ,?)), (Idn x const ant-view( V)), E P exp Exp => V) 

the-parameter(Pss , Idn, l\lam) 

parameter-action^, Pss, (Idn x formai(o«/_modc, S t , ?)), (Idn x VP), 27 h nam Nam M/) 

ti 2 e-parameter(Pss, Idn, Nam) 

pararneter-action(J£, Pss, (Idn x formal(vi-out- mode, S t ,?)), ( Idn x H / ),£ , H nam Nam => IT) 


gjVen„parameter(ldn => Exp • Pss, Idn, Exp) 


Idn i ^ Idn2 

given-parameter(Pss, ldn 2 , Exp) 
given-parameter(\dni =>? ■ Pss, ldn 2 , Exp) 


the-parameter(\6n => Nam • Pss, Idn, Nam) 


Idn i ^ ldn 2 

the-parameter(Pss , ldn 2 , Nam) 
the-parameter(\dn± =>? • Pss, ldn 2) Nam) 


4.12.5 Return Statements 

normal(N), E h stm return; => proc-return(N) 

Si, E h ejp Exp => K, /]ormal( A) 

Si, £ h 5tm return Exp; => func-return(constant-view( V), N) 

The following needs to be defined to describe the rules of [6.5(6)] through [6.5(21)]. 

not yet defined 

convert-return-value(S , W\,St, W^) 
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4.13 Attributes 


isscalar-type(Si , 5 1 5tp [i/ 5 ]) 
Iow__bound(range-of_subtype(Si } S* tp [L $ ])) = K 

/3ew-.object(5i , V, L, 5 2 ) 

S\, E, subtype~view(L s ) \~ att first => ohject-view(L, S^ tp [L s ], constant), S 2 

issca}ar-type{S\ , 5 1 5 * P [Z 5 ]) 
bigb_bound(ra/ige_o£_subtype(5i , 5 1 stp [£ s ])) = K 

new_object(Su V,L,S 2 ) 

Si,E } subtype-view(L s ) h att last => object-.view(L, S^ tp [L $ ], constant ), 5 2 

Si tp [L s ] = subtype( U, C , >1) 
is_jscaiar_type(5i 1 subtype( £/, C, >1)) 

/}ew_5»btype(5i , gub^ype( U , no-constraint , yl), X Q , ^2) 

5i, subtype- view(Z 5 ) b rt * t base => subtype_view(Z a ), 52 

S[ tp [L 5 ] = subtype(?, in dex^cons train t(R ■ tf s ), ?) 

new_object(Si, Iow_bound(R), L, S 2 ) 

5i, E , subtype_view(i; a ) b a ^ first =>> object_view(Z } 5 t , cojista^t), 52 

5 1 stp [£ s ] = subtype(? , index-Constraint(R * #*),?) 

new_object(5i , higb-bound^), L , 5 2 ) 

5i , subtype_view(Z 5 ) h a ^ last object^view(L, S t , constant), S 2 

SriLs] = subtype(? , index-Constraint(R • #5),?) 
iow_bound(A!) = discrete- va^A^/) 

St = subtype(universa/_m/e0er_t7i, no_constraint, ?) 
bigh-bound(tf) — discrete _ vai(AbO 

new_object(5i, discrete, va/(Mt - M + 1), L, 5 2 ) 

5i, £j subtype- vievv(5 a ) \- att length => object_view(Z, S t , constant), 52 

51 , £, b att first => object-view(Li , ?, ?), 52 

52, £, h a( * last object- vie w( l 2 , ?, ?), 5 3 

5 3 h content(Li) => Vj 
5 3 h content(L 2 ) 

5i, £, h fl « r range => maAe_range( V\, V<>), S 3 
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Chapter 5 


Exceptions and Optimization 


5.1 Introduction 

Version 5.0 of the Annotated Draft Ada 9X reference manual [4] contains language that obviates 
many of the problems associated with section 11.6 of the Ada 83 reference manual [10]. The purpose 
of this chapter is twofold. The first is to examine the Ada revision as represented by Version 5.0 
in light of the earlier Language Precision Team work in this area as published in the LPT Task 1 
report [9], The second is to discuss the consequences of the remaining problems that the semant ics 
of Ada 9X present in the areas of predictability and to offer suggestions for accommodating them 
in practice. The report concludes with a brief commentary on the Annotated Draft used to support 
this research. 


5.2 The Ada 9X revision of 11.6 

Section 11.6 of the Ada 83 reference manual contained explicit permissions to reorder operations 
or to omit some checks that might propagate predefined exceptions. In Ada 83 the notion of the 
“effect” of a program or of an operation was not as clearly defined as it is in Ada 9X and the language 
of the section gave rise to endless discussions such as those captured in AI-315. 

As revised, [11.6] contains two substantive paragraphs, (5) and (7). The first gives permission to 
avoid raising exceptions under some circumstances. The second permits more extensive reordering 
of operations than was generally considered permissible in Ada 83 by relaxing the requirements for 
state predictability when an exception handler is entered. 


5 . 2.1 [ 11 . 6 ( 5 )] 

This paragraph allows the implementation to avoid raising exceptions in the face of failures of 
predefined language exceptions under some circumstances. In the context of a clearer notion of 
“effect,” it is somewhat of an improvement over the language of Ada 83. Even so, the language used 
in [11.6] is less clear than it might be. Consider the language of [RM-83 11.6(7)]: 

A predefined operation need not be invoked at all, if its only possible effect is to 
propagate a predefined exception. Similarly, a predefined operation need not be invoked if 
the removal of subsequent operations by the above rule renders this invocation ineffective. 

In Ada 83 the term effect is not defined 1 and the meaning of the term is the subject of considerable 
discussion in AI-315 and elsewhere. The gist of many of the discussions concerns the case in which the 

‘The index entry for “effect” in [RM-83 Appendix I] is “[see: elaboration has no other effect]." 
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programmer has apparently written an operation that is sure to raise an exception as a “shorthand” 
for a raise statement. While this should be considered to be poor programming style, suppressing 
the operation leads to surprising effects. 

We note that Chapter 14 of the Ada 83 rationale 2 which deals with exceptions does not discuss 
the material contained in [RM-83 11.6] and a search through the text of the rationale for the root 
string “optimiz” does not provide any appropriate insight. 

From the discussions contained in AI-315 it appears that the primary need that the language of 
[RM-83 11.6(7)] is attempting to capture is the desire to remove code that is dead along its normal 
execution path even if executing it may (or is certain to) raise an exception due to the failure of a 
language-defined check. According to [11. 6(7. f)], the language of [RM-83 11.6(7)] is now reflected in 
paragraph [11.6(5)] which reads: 

An implementation need not always raise an exception when a language-defined check 5 

fails. Instead, the operation that failed the check can simply yield an undefined result. 

The exception need be raised by the implementation only if, in the absence of raising 
it, the value of this undefined result would have some effect on the external interactions 
of the program. In determining this, the implementation shall not presume that an 
undefined result has a value that belongs to its subtype, nor even to the base range of 
its type, if scalar. [Having removed the raise of the exception, the canonical semantics 
will in general allow the implementation to omit the code for the check, and some or all 
of the operation itself.] 

5. 2. 1.1 Defining undefined 

Unfortunately, the index for Version 5.0 contains exactly one entry for undefined result , i.e., [11.6(5)]. 
Although this reference purports to define undefined result ) we are given no useful semantics to 
associate with the term. Thus we are left to attempt to define exactly what is meant by the phrase 
through other means. A search of the source text for Version 5.0 yields several additional uses of 
the word undefined . The ones that appear to be related to its use in [11.6(5)] are: 

13.9.1 NOTES 

19 Objects can become abnormal due to other kinds of actions that directly update the 1 
object’s representation; such actions are generally considered directly erroneous, however. 

Wording Changes From Ada 83 

In order to reduce the amount of erroneousness, we separate the concept of an 1 

undefined value into objects with invalid representation (scalars only) and abnormal 
objects. 

Reading an object with an invalid representation is a bounded error rather than i 

erroneous; reading an abnormal object is still erroneous. In fact, the only safe thing 
to do to an abnormal object is to assign to the object as a whole. 

3.8.1 • The discrete_choice others covers all values of its expected type that are not covered by 1 

previous discrete_choice_lists of the same construct. 

Ramification: For case_statements, this includes values outside the range of 1 

the static subtype (if any) to be covered by the choices. It even includes values 
outside the base range of the case expression’s type, since values of numeric types 
(and undefined values of any scalar type?) can be outside their base range. 

7 4 

1 Extensions to Ada 83 

2 This document may be obtained by anonymous ftp from ajpo .sei.cmu.edu in the directory public/rationale. 
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The rules for too-early uses of deferred constants are modified in Ada 9X to 
allow more cases, and catch all errors at compile time. This change is necessary in 
order to allow deferred constants of a tagged type without violating the principle 
that for a dispatching call, there is always an implementation to dispatch to. It has 
the beneficial side-effect of catching some Ada-83-erroneous programs at compile 
time. The new rule fits in well with the new freezing-point rules. Furthermore, 
we are trying to convert undefined-value problems into bounded errors, and we were 
having trouble for the case of deferred constants. Furthermore, uninitialized deferred 
constants cause trouble for the shared variable / tasking rules, since they are really 
variable, even though they purport to be constant. In Ada 9X, they cannot be 
touched until they become constant. 

The first item seems to be the key. The remaining two items use the word undefined in ways that 
seem to confirm the impressions given by [13.9.1] as a whole. Thus, we see that undefined either 
applies to a scalar object with an invalid representation or to an abnormal object. Abnormal objects 
can either be produced by disrupted assignments (with a reference from [13.9.1(5)] back to [11.6], 
presumably to [11.6(6)]) or (for non-scalars) by a return from a call to either a language defined 
input procedure or to an imported procedure. It is, perhaps, stretching things to call the latter an 
operation in the sense of the discussion of [3.2]. 

Discussion: An operation is a program entity that operates on zero or more 

operands to produce an effect, or yield a result, or both. 

It seems more likely that the operations referred to are akin to the primitive operations partially 
defined in 3.2. 

A type is characterized by a set of values, and a set of primitive operations which 
implement the fundamental aspects of its semantics. 

This leads us to consider the invalid values that can be associated with scalar objects and the 
predefined operations on scalar types. These are discussed in general in [4.5] where the relevant 
language appears in [4 . 5(9)— 4 .5(12)]. 

For each form of type definition, certain of the above operators are predefined ; that is, 
they are implicitly declared immediately after the type definition. For each such implicit 
operator declaration, the parameters are called Left and Right for binary operators; the 
single parameter is called Right for unary operators. [ An expression of the form X op 
Y, where op is a binary operator, is equivalent to a function_cail of the form “op”(X, 

Y). An expression of the form op Y, where op is a unary operator, is equivalent to a 
function-call of the form “op”(Y). The predefined operators and their effects are described 
in subclauses 4.5.1 through 4.5.6. ] 


Dynamic Semantics 


[ The predefined operations on integer types either yield the mathematically cor- 
rect result or raise the exception Constraint-Error. The predefined operations on 
real types yield results whose accuracy is defined in Annex G, or raise the exception 
Constraint-Error. ] 

To be honest: Predefined operations on real types can “silently” give 
wrong results when the Machine-Overflows attribute is false, and the compu- 
tation overflows. 


Implementation Requirements 


The implementation of a predefined operator that delivers a result of an integer or 
fixed point type may raise Constraint_Error only if the result is outside the base range 
of the result type. 

The implementation of a predefined operator that delivers a result of a floating point 
type may raise Constraint-Error only if the result is outside the safe range of the result 
type. 

Unfortunately, there is a reading of this language that would make it impossible for a predefined 
operation on integer types to produce an invalid value. Paragraph (10) requires the operation to 
either yield the mathematically correct result or to raise Constraint-error. Paragraph (11) states 
that the implementation of the predefined operation may raise Constraint-error only if the result 
is outside the base range of the result type. Now, if we assume that “result” in paragraph (11) is 
the value produced by the implementation, it is almost certainly the case that this result will be 
within the range of the base type; it just will not be mathematically correct. It is likely that what 
is intended is 

The implementation of a predefined operator that delivers a result of an integer or 
fixed point type may raise Constraint-Error only if the [mathematically correct] result 
[of the operation] is outside the base range of the result type. 

As the language is currently defined, there is a direct contradiction between the language of 
[4.5(10-11)] and that of [11.6(5)] 

If we assume the revised interpretation, then we have a class of operations that can produce 
results that are not mathematically correct though they will typically be precisely defined by the 
implementation. If 11.6(5) is to have any reasonable meaning, it must be the case that results of this 
kind are the undefined results referred to. If this is the case, we have extended the notion of invalid 
to include representations of scalar objects that do represent values of the object’s subtype but are 
not the mathematically correct values that would be produced without the violated constraint. 3 
This is a fairly serious extension and deserves more consideration. We will return to this 
shortly. 


5. 2. 1.2 Use of undefined results 

The implementation note associated with [11.6(5)] seems to raise two distinct points. One, allowing 
the removal of dead code, is fairly obvious and seems to be the only clear-cut case. The other 
discusses implementation assumptions and seems to involve the extension noted above. 

Implementation Note: This permission is intended to allow normal “dead code re- s.a 

moval” optimizations, even if some of the removed code might have failed some language- 
defined check. However, one may not eliminate the raise of an exception if subsequent 
code presumes in some way that the check succeeded. For example: 

if X * Y > Integer’ Last then 5e 

Put_Line("X * Y overflowed"); 
end if; 

'^Addition in a 2 s complement n bit machine produces a result that is either a mathematically correct integer 
result or the mathematically correct integer result minus 2 n . Consider a 2 bit, 2’s complement machine. Its value set 
is given as 


h 

no 

+ 

00 ( 0) 

01 ( 1) 

10 (-2) 

11 (-1) 

00 

0 

00 ( 0) 

00 ( 0) 

01 ( 1) 

10 (-2) 

11 (_1) 

01 

1 and + defined as 

01 ( 1) 

01 ( 1) 

10 (-2) 

11 (-1) 

00 ( 0) where the values in italics are not 

10 

-2 

10 (-2) 

10 (-2) 

11 (-1) 

00 ( 0) 

01 ( 1) 

11 

-1 

11 (-1) 

11 (-1) 

00 ( 0) 

01 ( 1) 

10 (-2) 


mathematically correct integer results but are both well-defined and have a valid integer representation. 
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exception 

when others => 

Put_Line("X * Y overflowed"); 

If X*Y does overflow, you may not remove the raise of the exception if the code that does 
the comparison against Integer’Last presumes that it is comparing it with an in-range 
Integer value, and hence always yields False. 

As another example where a raise may not be eliminated: 

subtype StrlO is String(l . . 10) ; 
type P10 is access StrlO; 

X : P10 := null; 
begin 

if X . all 'Last = 10 then 
Put_Line("0ops") ; 
end if; 

In the above code, it would be wrong to eliminate the raise of Constraint_Error on the 
“X.all” (since X is null), if the code to evaluate ’Last always yields 10 by presuming that 
X.all belongs to the subtype StrlO, without even “looking.” 

The first point is that if the result of an operation is not subsequently used, then we can ignore the 
possibility that execution of an operation might have raised an exception. Examples that illustrate 
this situation are somewhat contrived since programmers generally do not try to write code that is 
not useful. For example, we might illustrate the permission by writing something like: 

subtype StrlO is StringC 1 . . 10) ; 

X : StrlO := M 
begin 

X := "2 01"; 

Put_line(X) ; 

X := "8 01234567"; 

Put_line(X) ; 

X := "10 0123456789"; 
exception 

when others => 

Put_Line("00PS") ; 

end ; 

Since the scope of X does not extend beyond the end of the block, the value produced by the last 
assignment has no effect along the normal path of execution. [11.6(5)] gives permission to ignore the 
possibility (in this case, a certainty) that the assignment will raise Constraint_Error. This, in turn, 
allows the elision of the entire assignment statement using conventional, “dead code” elimination 
techniques. 

Note that without the extra permission of [11.6(5)], the code for the last assignment is not dead 
since there is a a well-defined “effect” along the exceptional 4 path. The extra permission allows 
the implementation to restrict its analysis to the normal path. This is important since exception 
handlers are dynamically bound and an analysis that shows that an operation is dead along its 
exceptional path is generally intractable, while one that shows that the operation is dead along its 
normal path may require only local analysis. 

While the example is contrived, the situation that it presents appears fairly frequently as the 
result of other transformations during code generation and optimization. For example, unrolling 

4 See the definitions of exceptional find normal paths below. 
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a loop may well leave dead code in the final iteration, e.g., the code intended to initialize the 
next iteration. Value propagation and common subexpression elimination also serve to create dead 
variables and dead code to manipulate them. 

The language of [11.6(5)] does not ensure that the obviously intended meanings of some realistic 
examples will be preserved. For example, in AI-315, Robert Dewar presents the following example: 

function Add_overf lows (A , B: Integer) return Boolean is 

T: Integer 
begin 

T := A + B; 

return False; 
exception 

when Constraint_Error => return True; 
end Add_0verf lows ; 

The writer of code like this might hope to detect a potential overflow situation and, perhaps, 
use the knowledge to invoke an alternate more robust computation, however, it appears that the 
permissions of [11.5] would allow the constraint_error to be ignored, rendering the assignment dead 
and allowing its elimination permitting the function to always return False. This could cascade, 
if for example, the function were to be inlined, eliminating the code for the alternate computation 
which would also appear dead. 

Note that both Dewar’s example and the example of [1 1 .6(5.e)] have the same intent, the detection 
of overflow. They differ in minor details with respect to the way the overflow is detected. It is 
probably unreasonable to expect a casual (or even experienced) user of the language to detect the 
subtleties. Indeed, the casual observer ought to come to the conclusion that the example of [11. 6(5. e)] 
cannot work because the implementation result (as opposed to the mathematically correct result) of 
X * Y cannot possibly be larger than Integer 9 Last so that the first Put_Line cannot appear. This 
would lead the user towards an example similar to Dewar’s which apparently will not work. It is 
not clear that there is any easy fix. The approach offered with respect to code motion in [11.6(6)], a 
compromise that allows local code motion with local analysis, but does not insist on global analysis 
to ensure that the permitted code motion does not disrupt the canonical semantics might also 
apply here. This would require that analysis proceed along both the normal and exceptional paths 
following from an operation if there were an exception handler for the exception potentially raised 
by the operation associated with the innermost sequence of statements containing the operation. 

The examples given in (5.e) and (5.g) raise more subtle points. In the absence of [11.6(5)], 
Ada’s exception model is similar to that of Gypsy. If we use a Gypsy-like model to specify the 
Ada operations, we get a possibility of two execution paths from each operation [6]. We will call 
these paths the normal and exceptional paths. If none of the language-defined checks fail during 
the performance of the operation, execution proceeds along the normal path. If performance of the 
operation causes a language-defined check to fail, execution proceeds along the exceptional path. 
Associated with each operation is an entry specification which is assumed 5 to be true when the 
operation is invoked. Associated with each exit path is an exit specification which is guaranteed to 
hold if the path is followed. 

For example, the implementation of the integer multiplication operation on a given machine 
might be specified as follows: 

function Machine_Mul(X , Y : Machine_Integer) 
return Machine_Integer 

entry 

J “Assumed” is with respect to the operator definition. The implementation is required to “prove” that the as- 
sumption holds every time the operation is invoked. In the case of operations such as Hachine_Hul and Hachine-CHP 
all possible bit patterns represent valid values of Machine-Integer and the entry condition is trivially satisfied. 
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X, Y in (Machine_Integer ’First .. Machine_Integer ’Last) ; 
normal exit 

Machine_Mul (X , Y) = Integer_Mul(X , Y) and 

Machine„Mul(X, Y) in 

(Machine.Integer ’First . . Machine_Integer ’Last) ; 
exceptional exit 

Machine_Mul (X , Y) != Integer_Mul(X , Y) and 

Hachine_Mul(X, Y) in 

(Machine.Integer ’First .. Machine.Integer ’Last) and 

Integer„Mul(X, Y) not in 

(Machine_Integer ’First . . Machine__Integer ’Last) ; 

This says that for some (possibly empty) set of input values, machine multiplication is equivalent 
to abstract integer multiplication and that execution will proceed along the normal path when this 
is the case. When machine and integer multiplication do not produce the same result, we are told 
that the true result is not representable as a Machine_Integer but that some result 6 7 representable 
as a machine integer is produced.^ Now, if we look at a possible specification for the comparison 
operator, >, we see a potential problem with the language of the note. 

function Machine_CMP(X , Y : Machine_Integer) 
return Machine_CC 

entry 

X, Y in (Machine_Integer ’First .. Machine_Integer ’Last) ; 
normal exit 

Machine_CMP(X, Y) = GT implies Integer_GT(X , Y) and 

... — Specifications for other return values 
exceptional exit 

false ; 

In this case, we assume a comparison instruction at the machine level that sets some condition 
codes to indicate the results of the comparison. GT is a condition code value that indicates the first 
operand, interpreted as an abstract integer, was greater than the second operand, also interpreted 
as an abstract integer. Note that the only entry condition assumes that the inputs are machine 
integers. This condition is satisfied by the exit condition of the multiply operation under either its 
normal or exceptional execution. Note also that this operation is defined to always exit normally. 

We note that, in program verification, an operational semantics that allows exceptions to be 
raised when a language-defined check fails is, in a sense a dual of an operational semantics that 
produces an undefined result under the same circumstances. In the absence of a way to effect a 
meaningful recovery from failed checks, 8 we must show that the exceptional path is not taken. The 
proofs involved are exactly those that are required to show that operations do not produce undefined 
results. Languages such as Euclid and Verdi (and C for that matter) use an undefined semantics 
while Ada (in the absence of [11.6]) and Gypsy use an exception-based semantics. 

For formal reasoning, the differences are largely matters of style. From an implementation 
standpoint, unless it can be shown that a given program will not have effects based on undefined 
results, the choice is between being able to detect a departure from normal execution and not. 
[11.6(5)] requires that exceptions not be suppressed if suppressing them would lead to a visible 

6 For most machines, we could specify exactly what this result is, i.e., how to compute it as a function of X and Y. 
It is not undefined in the sense that we know nothing about it. 

7 The first conjunct is redundant since it could be deduced from the other two. 

8 By a meaningful recovery, we mean undoing or overcoming the failed operation in such a way that computation 
can resume execution along the normal path, satisfying all the implicit and explicit assumptions of that path. In 
practice, this is extremely difficult unless the specification of the normal computation is extremely weak. 
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effect due to the subsequent use of an undefined result. We will examine the process of substituting 
operator definitions that produce “undefined” results for those that raise exceptions. 

The stated assumptions associated with the example of [11 .6(5 .e)] are not sufficiently strong. In 
most machines, the result of an integer operation that fails an Ada implementation-defined check 
will be a valid value of the base type of the operation’s result and, in many cases, it will be a valid 
value of the appropriate subtype as well. Thus, the values supplied to the comparison operation 
will always be “in-range integer value”s. The value is not the issue. If we allow the operation to 
omit its exception check, we must consider the result to be more than a value for the purposes of 
analysis. In the abstract, the result of an operation that yields an undefined result must be seen as 
a object having two attributes, ’value and ’defined, ’value is of the base type of the result of the 
operation while ’defined is boolean. 

Under this view, multiply and compare might be defined as follows: 

function Machine_Mul(X, Y : Machine_Integer) 
return Machine_Integer 

entry 

X ’value, Y ’value 

in (Machine_Integer 'First . . Machine_Integer 'Last) and 

X’defined and Y’defined; 

exit 

if Machine_MUL’defined then 

Machine_Mul’value(X, Y) = Integer_Mul(X , Y) and 
Machine_Mul’value(X , Y) in 

(Machine_Integer 'First . . Machine__Integer 'Last) and 

else 

Machine_Mul’value(X , Y) != Integer.Mul (X , Y) and 
Machine_Mul’value(X , Y) in 

(Machine_Integer ' First . . Machine_Integer 'Last) and 
Integer_Mul(X , Y) not in 

(Machine_Integer 'First .. Machine_Integer 'Last) ; 

end if 

function Machine_CMP(X , Y : Machine_Integer) 
return Machine_CC 

entry 

X, Y in (Machine_Integer 'First . . Machine_Integer 'Last) and 

X’defined and Y’defined; 

exit 

Machine_CMP’defined(X , Y) and 

(Machine_CMP’value(X, Y) = GT implies Integer_GT(X , Y) and 

— Specifications for other return values) 

Under this view of operational semantics, the obligation to take appropriate action in the case 
of exceptional operations has shifted from the operation making the check to the operation using 
the result. The substitution of “undefined” semantics for “exception” semantics might be done as 
follows: 

1. Tentatively replace an operation using “exception” semantics with the equivalent operation 
using “undefined” semantics. Note that this substitution is dependent on being able to prove 
the stronger entry specification of the latter. 9 

9 In the implementation of a language using the “undefined” semantics, we note that there is, in general, no way 
to determine by inspection that a given bit string represents an “undefined” value. A two’s complement machine 
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2. If it is possible to prove that the ’defined attribute of the operation’s result is always true 
then the substitution is permitted (see the ramification [11. 6(5. a)]) and no further analysis is 
required. 

3. Locate all uses of the result of the replaced operation. If there are none, the substitution is 
permitted. If there are any, substitute the corresponding “undefined” semantics operation, 
if necessary, and check the entry specification for references to the ’defined attribute of the 
result in question. If any using operation assumes that the ’defined attribute of the result is 
true, the substitution cannot be made. 

If the substitution can be made, the net effect is to remove from further consideration the 
execution path arising from the exception exit of the replaced operator definition. This, in turn, 
should enable additional program transformations, including removal of the replaced operation since 
it is known to be without an externally visible effect. The removal of the exception path may permit 
additional removals since dependencies along the path no longer require consideration. Removal of 
the operation may permit additional operations to be removed since its inputs are now referenced 
at fewer places. 

Note that this is an analytical approach, not an implementation. Typically, there is no practical 
way to tag values with an indication that they represent an “undefined” result. When this is the case 
there is no way for subsequent operations in an implementation to check explicitly for the undefined 
property. In addition, the amount of analysis required to detect all uses of a result may require 
extensive reasoning about the values of index expressions, etc., when the values are components of 
arrays or other composite structures. 

Implicit in the assumption of the last paragraph of [11. 6(5. e)] appears to be an additional assump- 
tion that the values being compared are also the mathematically correct results of the operations 
that produced them, i.e., that they are not undefined. 

It is probably the case that the only permission actually granted by [11.6(5)] is the removal of 
code that is “dead” along its normal exit path regardless of any effects along its exceptional exit 
path. 


5.2. 1.3 Bounded errors and erroneous executions 

The Ada 9X revision has made a serious attempt to reduce the number and types of circumstances 
under which a program’s execution can become erroneous. Since an erroneous execution can exhibit 
arbitrary behavior, this change is highly desirable. Recognizing that most implementations do 
reasonable things in the face of program errors that violate language semantics, the notion of a 
bounded error has been introduced. The bounded errors associated with invalid representations are 
discussed in [13.9.1] 

Bounded ( Run-Time ) Errors 


If the representation of a scalar object does not represent a value of the object’s 9 

subtype (perhaps because the object was not initialized), the object is said to have an 
invalid representation. It is a bounded error to read the value of such an object. If 
the error is detected, either Constraint_Error or Program-Error is raised. Otherwise, 
execution continues using the invalid representation. The rules of the language outside 
this subclause assume that all objects have valid representations. The semantics of 
operations on invalid representations are as follows: 

• If the representation of the object represents a value of the object’s type, the value 10 

of the type is used. 


addition, for example, operating on two n bit long bit strings interpreted as integers produces an n bit long bit string 
that can be interpreted as an integer congruent to the mathematically correct integer result modulo 2 n . Because of 
this, the entry specifications cannot be executed but must be reasoned about. 
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• If the representation of the object does not represent a value of the object’s type, n 

the semantics of operations on such representations is implementation-defined, but 
does not by itself lead to erroneous or unpredictable execution, or to other objects 
becoming abnormal. 

Erroneous Execution 

A call to an imported function or an instance of Unchecked_Conversion is erroneous 12 

if the result is scalar, and the result object has an invalid representation. 

Ramification: In a typical implementation, every bit pattern that fits in 12 

an object of an integer subtype will represent a value of the type, if not of 
the subtype. However, for an enumeration or floating point type, there are 
typically bit patterns that do not represent any value of the type. In such 
cases, the implementation ought to define the semantics of operations on the 
invalid representations in the obvious manner (assuming the bounded error is 
not detected): a given representation should be equal to itself, a representation 
that is in between the internal codes of two enumeration literals should behave 
accordingly when passed to comparison operators and membership tests, etc. 

We considered requiring such sensible behavior, but it resulted in too much 
arcane verbiage, and since implementations have little incentive to behave 
irrationally, such verbiage is not important to have. 

If a stand-alone scalar object is initialized to a an [sic] in-range value, then 12 

the implementation can take advantage of the fact that any out-of-range value 
has to be abnormal. Such an out-of-range value can be produced only by things 
like unchecked conversion, input, and disruption of an assignment due to abort 
or to failure of a language-defined check. 

This depends on out-of-range values being checked before assignment (that 
is, checks are not optimized away unless they are proven redundant). 

The language of the Ramification sounds reasonable, but it flies in the face of the conventions 
used in many of the logics used to reason about program behavior. Typically, undefined is a loaded 
term in these logics. Undefined is used to represent a distinguished value about which nothing can 
be proven. Thus \f undefined = undefined. This is too strong for implementation semantics in most 
cases. In any implementation in which evaluating x is free of side effects that could change its value, 
x = x is true even if x has an invalid representation or is undefined so long as the implementation 
of = simply involves comparing bit patterns. In the absence of a requirement to actually evaluate 
x , it should be unconditionally ok to substitute true for the equality. 

On the other hand, this language seems to have the potential for conflicts with semantics of 
“undefined” results discussed above in connection with [11.6(5)]. The relationship between undefined 
as used in [13.9.1] and [11.6(5)] should be further clarified. 

5 . 2.2 [ 11 . 6 ( 7 )] 

This paragraph allows fairly arbitrary reordering of actions within the scope of an exception handler 
by reducing the expectations that the programmer may have concerning the state of the computation 
at the time that the handler is entered. This is essentially the “Undefined” execution order of [9, 
section 2.6.5]. We note that the only effective actions that a programmer can take when an exception 
handler is entered in the face of this kind of reordering is to assign normal values to all variables 
that might have become abnormal due to operations disrupted by the exception. 

The first sentence of this paragraph is complex and convoluted and calls out to be simplified or 
clarified. The following discussion may aid in finding more suitable language. An exception_handler is 
opt ionally associated with a handled_sequence^of_statements which contains a sequence_of_statements 
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and is, among other things, the operational portion of a task_body. When an exception is raised, it 
will either be handled or cause the containing task„body to terminate. In either case, all that the 
user can expect to know is that the exception was raised somewhere in the code of the sequence_of_ 
statements component of the handled_sequence_of_statements that contains the exception_handler 
just entered or that constitutes the operational part of the task being terminated. The reordering 
that can be done is limited in two respects. 

1. The operation that raises the exception due to a failed language-defined check cannot have 
been moved into the code of an independent subprogram, and 

2. The operation that raises the exception due to a failed language-defined check cannot have 
been moved into the code of some abort-deferred operation. 

Just breaking up the sentence may help. Instead of 

• If an exception is raised due to the failure of a language-defined check, then upon reaching the e 
corresponding exception-handler (or the termination of the task, if none), the external inter- 
actions that have occurred need reflect only that the exception was raised somewhere within 
the execution of the sequence_of__statements with the handler (or the task-body), possibly ear- 
lier (or later if the interactions are independent of the result of the checked operation) than 
that defined by the canonical semantics, but not within the execution of some abort-deferred 
operation or independent subprogram that does not dynamically enclose the execution of the 
construct whose check failed. 

perhaps language similar to the following would be more understandable. 

• If an exception is raised due to the failure of a language-defined check, then upon reaching « 
the corresponding exception_handler (or the termination of the containing task, if no handler 

is present), the external interactions that have occurred need reflect only that the exception 
was raised somewhere within the execution of the sequence_of-statements associated with the 
handler (or the task_body). It may appear that the exception was raised earlier than defined 
by the canonical semantics (or later if the interactions are independent of the result of the 
checked operation). It may not appear as if the exception were raised within the execution 
of some abort-deferred operation or within the execution of an independent subprogram that 
does not dynamically enclose the execution of the construct whose check failed. 

5.3 Living with the “Canonical Semantics” 

The canonical semantics define a potentially very large family of valid executions. This is due to the 
numerous places in which the language definition allows operations to be performed in an arbitrary 
order. An implementation is free to select any order under these circumstances. In the absence of 
order dependencies and tasking considerations, all canonical executions should produce the same 
externally visible effect. Order-dependent side effects, including exceptions raised due to the failure 
of language-defined checks, can affect the effect of the program. The problem is twofold: 

1. Reducing the potential effect space of the program, and 

2. Determining which execution the implementation has selected. 

First of all, it is worth noting that this kind of problem is not unique to Ada (both Ada 83 
and Ada 9X). Most programming languages, including C and C++, admit similar behaviors, either 
implicitly or explicitly. Ada is more explicit about them. In general, the failure of languages to 
define or enforce restrictive canonical executions is attributed to a need for flexibility in order to 
achieve run-time efficiency. There is tension between this need and the requirements for predictable 
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program behavior, which are imposed by small segments of the user community, typically those users 
associated with safety and security critical applications. Predictable behavior is usually defined as 
having a rigorous semantic definition that allows the formal verification of programs written in the 
language, preferably using mechanical aids. 

In theory, one could reason about Ada programs by enumerating the set of possible executions 
and reasoning individually about each one. A program could then be said to shown to exhibit a 
given property if each of its possible executions could be shown to exhibit the property. In practice, 
the combinatorics of potential execution choices are likely to render this approach infeasible for any 
non-trivial program. If we assume that a compiler conforming to the language standard produces 
code that follows one of the set of canonical executions of a given program, it seems a waste of time to 
prove properties of the set as a whole unless there is a need to guarantee the behavior of the program 
under all possible conforming implementations. This is seldom the case. Further complications arise 
when it is possible to show that some, but not all, members of the canonical execution set exhibit 
the desired property. In this case, it is essential to determine whether the implementation being 
considered exhibits the property. 

There are several possibilities. The first is to attempt to reduce the size of the set of canonical 
executions to a tractable size and possibly to a single member. The second is to discover the member 
of the canonical execution set that has been chosen by a particular implementation and to reason 
about that execution alone. 


5.3.1 Restricting the execution set size 

The size of the canonical execution set about which one must reason can be reduced by one of 
two methods; reducing the choices available to the implementation or finding equivalence classes 
within the set, or by some combination of the two. Ada 9X provides some means for imposing 
order. For example, the order of the association of operands with a sequence of operators of the 
same precedence can be controlled by the explicit use of parentheses. The introduction of explicit 
intermediate variables and assignments should have a similar effect. For example, suppose that 
side effects exist such that the value resulting from the evaluation of <expl> depends on whether 
it is evaluated before or after <exp2>, but that there are no other order dependencies between the 
expressions. Further assume that the evaluations produce results of some integer subtype. 

A := <expl> + <exp2>; 

Either of the possible results is a member of the canonical execution set for this fragment. If we 
want to ensure that <expl> is evaluated first, we might write: 

A1 := <expl>; 

A2 := <exp2>; 

A := A1 + A2 ; 

It is not clear that the additional freedoms to reorder operations granted by [11.6(6)] allow an 
implementation to ignore structuring of this kind, but aggressive optimizations in compilers for 
other languages are known to do so in some cases. Presumably, the dependency between the two 
expressions either becomes explicit or the implementation will be forced to recognize that it cannot 
assume independence because the expressions invoke separately compiled routines and it will be 
forced to produce the intended result 10 . 

Note that the explicitly ordered code may still exhibit a family of canonical executions. In the 
expression A1 + A2, the language allows A1 or A2 to be “evaluated” first. We claim that given 

the expressions are sufficiently complex and the dependencies between them limited, it may be possible to 
interleave their evaluations. This would be permitted under the general freedoms noted in [11.6(3)] 
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appropriate type declarations (and barring some pathological implementation of +) that both orders 
will be equivalent and trivial. 

By a combination of these two techniques, forcing orders where order makes a difference and cre- 
ating situations where it is easy to show that, at least locally, all canonical executions are equivalent, 
it should be possible to reduce the number of canonical executions associated with a program to a 
tractable number. In most cases, the analysis of the remaining canonical executions should show 
that language-defined checks will not fail, rendering moot the freedoms of [11.6]. The utility of this 
approach depends on the implementation or implementations of interest ensuring that the canonical 
semantics are honored. 

If the notion of a subset of Ada 9X for High Integrity systems, as recently proposed by Brian 
Wichmann, is accepted, the subset definition could restrict the ordering freedoms permitted by the 
primary language definition. This approach would necessitate subset compilers to enforce the re- 
strictions, but would offer a higher degree of assurance than the use of general purpose compilers. 
If a subset is adopted with the notion of supporting mechanical verification, it is not unreason- 
able to expect that integrated environments will be developed in which both the verification and 
implementation tools are based on the same semantic assumptions. 

5.3.2 Discovering the execution 

Another approach to the problem of a canonical execution set is the determination of the actual 
execution produced for a given program by a given implementation. This requires that the compiler 
output its object code in a form that allows the user to determine the actual execution that will occur 
when the program is executed. Implementations conforming to the Safety and Security Annex, in 
particular to section [H.3], will provide this kind of information. With an appropriate transformation 
of the object code back into an appropriate Ada or Ada-like source form, it should be possible to 
perform source level analysis or verification on the program while maintaining confidence that the 
results are, in fact, applicable to the compiled program. 

It is clear that this approach requires facilities that are not present in many, if not all, existing 
compilers, but the Annex should encourage development of this facility. 


5.4 Observations on the Reference Manual 

In the course of using the Reference Manual in the preparation of this chapter, a number of general 
shortcomings have been observed. These have more to do with presentation than with substance 
and can be fixed prior to the release of the final document. 

First of all, we wish to compliment the Mapping/Revision Team on the content and style of the 
manual. Not only is the wording a substantial improvement over the Ada 83 Reference Manual, 
but the inclusions of the annotations provide useful and substantive insight into the workings of the 
language. It is to be hoped that the annotated version will be maintained along with its “official” 
subcomponents and that it will see widespread use by serious students of Ada 9X. 

This said, there are ways in which the the Reference Manual could be further improved. 

1. The index is not sufficiently comprehensive. On a number of occasions, an attempt to trace the 
consequences of a definition found that the defining occurrence was the only reference in the 
index. Fortunately, the source files are available and can be searched as necessary; however, 
any term important enough to be marked as a definition is important enough to have the 
consequences of that definition tracked. A presentation similar to that used in the index for 
syntactic constructs should be adapted for defined terms, i.e., a defining reference followed by 
using references. 

2. The index does not appear to cover the annotations. Extending it to this level would greatly 
aid in the use of the annotated manual. 
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3. The Syntax Cross-Reference would be much more useful if references for the defining occurrence 
as well as the using occurrences were given. For example, we find from the cross-reference that 
a task_body is used in the definition of a proper_body in [3.1 1], but we must go to the main index 
to discover that a task_body is defined in [9.1(6)]. Extending the indexing to the numbered 
paragraph level as is done in the index would also be useful. 

4. The marginal paragraph numbering is incomplete and inconsistent. For example, the para- 
graphs following the example codes of [1 1 .6(5. e)] and [1 1 -6(5 .g)] are not numbered while similar 
paragraphs elsewhere, e.g., [8. 3(29. o)] are. There is a similar problem in [13. 9. 1(12. b)] as well. 
This is probably the result of the mechanical approach taken to inserting the annotating scribe 
commands. In preparing the I^Tj^X source for the Annotated version of the Ada 83 reference 
manual, I found it necessary to insert this material manually. 

5. In some cases, precision seems to have been sacrificed for readability. This occurs when it 
is difficult to determine the antecedents for pronouns or where the same noun appears in an 
ambiguous context. An example is [4.5(H)] discussed in Section 5. 2. 1.1 on page 87 above. 
More liberal use of the ©Redundant (or a similar) construct might alleviate this problem in 
the annotated version. 
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Chapter 6 

Conclusions 


We did not expect to formulate a complete semantic definition (even for the sequential part of Ada) in 
this project; there were simply not enough resources to do so. What we did expect was to gain some 
insights into the structure of the language, and to identify some problems either with the description 
in the Reference Manual or in the design of the language itself, and to contribute to the development 
of Ada 9X by suggesting improvements to the description or design. Those expectations were met 
to some degree; for example, we identified some flaws (that have now been fixed) in the design in 
the area of per-object constraints; we identified some conceptual and some wording problems in the 
area of floating point and developed a model that was used in the development of new wording for 
the Reference Manual; and we identified some incompleteness in the description of actual subtypes. 

However, we did not make as much progress in the natural semantics definition as we had 
originally hoped. It was more difficult to understand the supposedly trivial parts of the language 
than we had imagined. Large-scale languages like Ada do not have neat, independent parts; rather, 
each feature is affected in some measure by the others. For example, the type system is affected by 
the concurrency mechanism (e.g., task types), by the packaging mechanism (e.g., private types), and 
in several ways by the object-oriented features (e.g., access discriminants, per-object expressions, 
class-wide types). So, indeed, there are no really trivial aspects of the language. In the original 
LPT project, we had felt that it would be a waste of effort to develop a formal model for things 
that “everyone understands”. Our recent efforts, however, have shown us that there are interesting 
problems lurking at the fringes of even these areas. 

Even though there are serious gaps in the definition, a considerable amount of groundwork 
has been done. We have identified most of the basic semantic domains that must be used in a 
full definition, we developed structuring mechanisms for the definition that allow us to describe 
many of the implementation freedoms, and we have several tools (such as the type checker for the 
Prolog representation of the definition, and the tool that derives RTjr;X source from the Prolog 
representation) that help in the production and documentation of the definition. So, we feel that 
we have made a good start in the direction of a complete description of the sequential part of the 
language. 

We are not sure how easily our framework could be adapted to deal with concurrency. The 
influence of tasking in DDC’s formal definition of Ada 83 [1] is pervasive, and we suspect that 
incorporating concurrency into our definition would similarly affect every part of the model. 


6.1 Implementation Freedoms 

One impediment to writing a formal definition like ours is the high degree of underspecification 
in the Reference Manual. This allows implementations considerable freedom to choose orders of 
actions, accuracy of results, base ranges of types, and so on. These freedoms can be difficult to 
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model; where an implementation need only produce one acceptable result, our semantics tries to 
describe all acceptable results. 

Modeling these freedoms sometimes forces our formal model to differ in significant ways from an 
implementation (and to use representations that no implementation is likely to use). For a simple 
example, consider the following rule about access-to-subprogram values: 

Two access-to-subprogram values are equal if they are the result of the same evalu- 
ation of an Access attribute_ref erence, or if both are equal to the null value of the 
access type. Two access-to-subprogram values are unequal if they designate different 
subprograms. It is unspecified whether two access values that designate the same sub- 
program but are the result of distinct evaluations of Access attribute_ref erences are 
equal or unequal. 

I]] order to model this, we are forced to use a representation of access-to-subprogram values that 
consists of both a reference to the designated subprogram and an “instance” value that tells which 
evaluation of an Access attribute gave the access value. Each evaluation of an Access attribute 
increments this instance value, so that we can determine whether two access values derive from the 
same evaluation or not. Our definition of the equality function checks both the subprogram reference 
and the instance number, and can give a result of equal, unequal, or unknown. Such a representation 
is unlikely to be used in any implementation of Ada 9X. 

An implementor of the language need not be concerned with all these freedoms; just one particular 
implementation choice needs to be made and the existence of other possible choices is irrelevant. 
A programmer does not necessarily need to be concerned about all the alternative orders; it is 
usually possible to write programs in such a way that the specific choice made by an implementation 
does not matter (for example, by avoiding side effects in functions, restricting the statements in a 
package_body to affect only variables local to the package, and so on). On the other hand, anyone 
trying to read an Ada program may indeed be concerned about the different possible outcomes of 
an execution (especially if the writer has not been careful to avoid situations where the different 
orders matter). So, our model, while unnatural if compared to an implementation, is quite natural 
a -s a description of the complexities that careful readers must deal with. 


6.2 Notation and Tools 

The natural semantics framework seems to have worked fairly well, although there were a few 
awkward aspects to our formalization of the language semantics. In particular, our need to introduce 
explicit sequencing and arbitrary-order combinations of actions (in two slightly different variations) 
seems somewhat artificial. However, this mechanism of actions allows us to present reasonably 
concise descriptions of many language features. 

The use of Prolog to make the definition executable (and type-checkable) was a. great help. We 
have been able to execute parts of the definition to confirm that it expresses what we intended. The 
type checker was able to find a number of trivial errors in our semantics. There is some price to 
be paid, hovever; it is sometimes inconvenient to express a rule in a manner acceptable to Prolog. 
This is particularly evident in the descriptions of the various semantic domains and the primitive 
functions acting over those domains. Prolog does not support defined functions (instead, relations 
must be used). We used a program to convert the Prolog code into the I^TgX source used for this 
report. This program is able to introduce functional notation in places where we have instructed 
it to, so at least our published form of the rules can use a more expressive notation than Prolog. 
But this is still rather unsatisfactory. It is possible that other tools might be able to provide better 
mechanical support. 
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6.3 Bounded Errors 


A number of rules and concepts were added to Ada 83 in order to make programs more predictable. 
For example, many situations leading to erroneous executions in Ada 83 have been made into 
bounded errors. For these errors, a range of possible outcomes is described. This seems like a 
beneficial change. However, there is a price to be paid for this benefit: the model for a feature 
using bounded errors can be substantially more complex than a model using erroneous executions. 
For example, in order to change the evaluation of an uninitialized scalar variable from erroneous 
to a bounded error, it was necessary to introduce the notion of “invalid representations” of scalar 
objects. The addition of this notion has an influence on a number of other areas of the language 
(e.g., relational operators, membership tests, and type conversions). So, the formal model is more 
complex, which means that formal predictions about programs are harder to derive. On the other 
hand, the execution of programs is more predictable in the sense that these executions are more 
constrained (the old rules allowed any behavior, whereas the new rules are more specific). 

6.4 Structure of Models 

It does not seem possible, using our methods, to formulate a model for Ada 9X that is simultaneously 
concise, comprehensible, broad, and accurate. Accounting for all the special cases of features adds 
so much detail to the model that it becomes unusable. 

Textbook writers face a similar dilemma; if too much detail is presented, readers will find the 
text impenetrable. Therefore, authors present simplified descriptions of parts of the language. These 
simplified descriptions, even when they lead the reader to draw incorrect conclusions about the 
behavior of some programs, are nevertheless useful to readers who are first learning the language. 
In a later part of a book, an author may elaborate on some of these missing details, and may need 
to contradict some of his earlier oversimplified assertions. 

We do not know exactly how to make layered formal models using a similar structure. In most 
formal notations, it is not possible to override an earlier assertion with a more detailed assertion. 
Even if this were allowed, it is unclear how a user of such a layered formal model would know when 
the simpler part of model was applicable. 

In the model developed in this report, we have tried to approach this ideal of structured models 
in a very modest way through our use of the “unpredicted” outcomes to simplify the formal model; 
we can certainly imagine a more complex version of this model that would, in fact, make predictions 
where this simpler model refuses to. However, we have not had the resources to develop the more 
complex model. 
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Appendix A 


Official comments submitted 


This appendix lists the official comments submitted by the LPT. For each comment, we give its 
official “key” number, its title, and a short description of the comment or its effect on the Standard. 

Comment 93-3209. a: Too much extra permission to remove checks . The conceptual framework 
of section 11.6 has been changed. 

Comment 93-3398. a: per-object constraints and the “ current instance ”. A new rule [3.8(13)] has 
been added to avoid the problem described. 

Comment 93-3511. a: What is the base range of an enumeration type?. 

Comment 93. 3547. a: constants that aren’t. The problem described has been identified as an 
erroneous execution in [13.9.1(13)] 

Comment 93-3547. b: subcomponents that are constrained by their initial value .. A new legality 
rule [3.6(H)] was added. 

Comment 93-3547. c: conversion to a type with aliased components. A new legality rule [3.6(H)] 
was added. 

Comment 93-3574. a: interleaving evaluation and conversion. Several paragraphs have been mod- 
ified to clarify the rules. 

Comment 93-03574. b: reassociation of sequences of predefined operators . A note [4. 5(13. b)] has 
been added to the Annotated Reference Manual. It is unclear, however, that the note clarifies the 
issue raised in this comment. 

Comment 93-3575. a: aliased subcomponents with per-object constraints. A new legality rule 
[3.6(H)] was added. 

Comment 94-3621. a: Initialize a discriminant before any subcomponents that depend on it. This 
clause has been added to the rules of [3.3.1(20)]. 

Comment 94-3760. a: Phraseology. An inaccurate statement has been reworded in [M(l)]. 

Comment 94-3761. a: Phraseology. Some wording in [3.3] has been improved. 

Comment 94-3762. a: Phraseology. 

Comment 94-3763. a: Phraseology. The wording of [3.2.3] has been clarified. 

Comment 94-3764. a: Phraseology. A clarifying cross-reference was added. 

Comment 94-3765. a: Phraseology. 

Comment 94-3901. a: Are first subtypes of enumeration types constrained?. A clause has been 
added to [3.5.1(10)] to answer this question. 

Comment 94-390 l.b: First subtypes of discriminated types are unconstrained. This clause has 
been added to [3.7(26)]. 

Comment 94. 3901. c: First subtypes of incomplete types. A new note in the [3. 10. 1(10. a)] Anno- 
tated Reference Manual argues that this issue is unimportant. 

Comment 94.390 1 . d : Predefined operators and invalid scalar components. The entire discussion 
of “invalid” scalars has been modified in version 5.0 of the Reference Manual. This comment and 


102 



the following two are cited in the changes. 

Comment 94-4045. a: Model for valid and invalid values. See above. 

Comment 94-4054. a: Model for valid and invalid values . See above. 

Comment 94-4064. a: What is the actual subtype of a formal object?. The question has been 
answered in [6.4.1(15)]. 

Comment 94-4065. a: Normalizing composite objects. An explicit statement about restoring ob- 
jects to normal state appears in [13.9.1(7)]. 

Comment 94-4 149. a: Incomplete definition of ’ expected profile ' and ’corresponding parameter’. 
Some rules have been clarified 

Comment 94-4171. a: Actual subtypes and aliased views. The rules in [3.10(9)] have been re- 
worded. 

The remaining comments were sent too late to affect version 5.0 of the Reference Manual. Some 
of them are addressed in the electronically-distributed version 5.3, as noted below. Furthermore, the 
floating-point annex is under revision to address some of the comments on the floating-point model. 

Comment 94-4448. a: Signed zeroes not permitted as floating point values. 

Comment 94-4454. a: Model-oriented floating point attributes. 

Comment 94-4455. a: Relation between requested precision and model numbers. 

Comment 94-4481. a: Inappropriate references to Annex G . 

Comment 94-4482. a: Are SWodel, S ’Machine deterministic?. 

Comment 94-4486. a: Symmetry of floating point types. 

Comment 94-4489. a: Derivation from a floating point type. 

Comment 94-4535. a: Derived types with new discriminants are extensions. A sentence has been 
added. 

Comment 94-4535. b: Discriminants used in constraints in derived type definitions. 

Comment 94-4535. c: Incorrect rules for uses of new discriminants in constraint on parent. A 
new rule has been added. 

Comment 94-4535. d: Current instance of a derived type. A note has been added in a “to be 
honest” section of the A ARM. 

Comment 94-4572. a: An object that is not {a part of} a formal parameter. 

Comment 94-4572. b: For aliasing, the type of the formal , not the part, matters. 

Comment 94-4572. c: When does an access path exist?. 

Comment 94-4587. a: Incompatibility between semantics of the core and annex G?. 

Comment 94-4796. a: reading a composite with an uninitialized scalar component. The wording 
of this rule has been changed. 
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Appendix B 

Intermediate Syntax 


* 


This appendix describes the decorated abstract syntax representation of Ada 9X programs. This 
representation includes all static semantic information needed for defining the dynamic semantics. 

One approach, not taken here, is to define a representation of semantic information such as types, 
subtypes, and overload information and defining necessary tree attributes. Instead of using semantic 
attributes we chose to give a purely syntactic representation of necessary information by introducing 
new kinds of tree nodes and new synthetic names. 

For instance, the results of overload resolution are captured by the introduction of new unique 
names and suitable renaming of overloaded entities and their use. Crucial type information is 
represented using existing syntax for qualified expressions. Thus the result of static semantic analysis 
is a normalized abstract syntax tree. The details of this normalization are described below. 

Declarations that introduce multiple names are replaced by static analysis with multiple decla- 
rations introducing single names where this is legal. 

Constructs for which no abstract syntax is provided are either not treated in this definition 
(e.g., tasking) or have not significance for the dynamic semantics (e.g., generics). 

B.l Syntactic Domains 

The following is a complete listing of the term algebra used to represent abstract syntax trees. The 
constructors are grouped by sorts and are arranged alphabetically. 


B.1.1 Component Associations (Aca) 


B.l. 2 Aggregates (Agg) 


arr ay _comp$ assoc : 

Dcii*, Exp — ► 

tgg) 

ext$agg : 

Exp, Rea* — ► 

named_array$agg : 

Aca* — ► Agg 

null_ext$agg : 

Exp Agg 

null_record$agg : 

-* Agg 

other_array$agg : 

Exp , Exp — 

pos_array$agg : 

Exp* -+ Agg 

recordSagg : 

Rea* -* Agg 


Agg 
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B.1.3 

B.1.4 

B.1.5 

B.1.6 

B.1.7 

B.1.8 

B.1.9 

B.1.10 

B.1.11 


Case Alternatives (Alt) 


A/tSlst : list(Alt) — ► Alt 

case $ Alt : Dch* , Stm — + Alt 


Choice Lists (Cel) 


list$choice : 

id* Cel 

othersSchoice : 

— Cel 

Context Items (Cit) 

withScontext : 

Nam* — ► Cit 

Component Declarations ( Cmp ) 

aliased_comp$decl : 

Id, Sid — » Cmp 

comp$decl : 

Id, Sid — ► Cmp 

init_aliasecLcomp$decl : 

Id, Sid, Exp — ► Cmp 

init_comp$decl : 

Id, Sid, Exp — ► Cmp 

Compilation Units (Cmp) 

libSunit : Cit*, 

Del — ► emu 

private$unit : Cit*, 

Del — ► emu 

subSunit : Cit*, 

Nam, Del — ► emu 

Conditions (Cnd) 

Exp$condition : 

Exp Cnd 

Constraints (Cns) 

constr_delta$constr : 

Exp, Cns — ► Cns 

constr_digits$constr : 

Exp, Cns — ► Cns 

deltaSconstr : 

Exp — ► Cns 

digitsSconstr : 

Exp — * Cns 

discrSconstr : 

Dca* — ► Cns 

indexSconstr : 

Rng * — ► Cns 

rangeSconstr : 

Rng — ► Cns 


Discriminant Associations (Dca) 

namedSassoc : Id, Exp — ► Dca 

Discrete Choices (Dch) 

discr_other$choice : — ► Dch 

expSchoice : Exp — ► Dch 

range$choice : Rng — ► Dch 
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B.1.12 


B.1.13 


B.1.14 


B.1.15 


Declarations (Del) 


dclSlst : 

list (Dei) — ► Del 

a_c_i_obj$decl : 

Id, Sid , Exp —> Del 

a_c_obj$decl : 

Id, Sid — Del 

a_i_obj$decl : 

Id, Sid , Exp — ► Del 

SL_obj$decl : 

Id, Sid — Del 

c_i_obj$decl : 

Id, Sid , Exp — ► Del 

c_obj$decl : 

Id, Sid — Del 

real_const$decl : 

Id, Exp — ► Del 

int_const$decl : 

Id, Exp — ► Del 

d_ext$decl : 

Id, Dcp , Sid — ► Del 

d_i_type$decl : 

Id, Dcp — ► Del 

d_type$decl : 

Id, Dcp, Tdf — ► D< 

exception$renaming 

: Id, Nam — ► Dei 

excpt$decl : 

Id — Del 

extSdecl : 

Id, Sid — Dei 

LobjSdecl : 

Id, Sid, Exp — ► Dei 

LtypeSdecl : 

Id — Dei 

obj$decl : 

Id, Sid — Dei 

objectSrenaming : 

Id, Nam, Nam — ► Dc 

s_subp$spec : 

Sps — + Dei 

subpSbody : 

Sps, Dei, Stm — ► Dei 

subpSrenaming : 

Sps, Nam — ► Del 

subpSspec : 

Sps — ► Del 

subtype$decl : 

Id, Sid Del 

type$decl : 

Id, Tdf — ► Dei 

c_type$decl : 

Id, Tdf — ► Dei 

c_d_type$decl : 

Id, Tdf, Dcp— ► Dei 

Discriminant Parts ( Dcp ) 

boxSdiscr : 

— ► Dcp 

listSdiscr : 

Dcs* — ► Dcp 

Discriminant Specifications (Dcs) 

accSdiscr : 

Id, Nam — ► Dcs 

acc_init$discr : 

Id, Nam, Exp — ► Dcs 

initSdiscr : 

Id, Nam, Exp — ► Dcs 

simple$discr : 

Id, Nam — ► Dcs 


Exception Choices ( Ech ) 

named$excpt : Nam — ► Ech 

othersSexcpt : — ► Ech 


106 


B.1.16 


B.1.17 


B.1.18 


B.1.19 


Else- If Clauses ( Eif) 

eif$lst : Eif* — ♦ Eif 

elsifSclause : Cnd, Stm — *■ Eif 


Expressions (Exp) 


and_then$ Exp : 

Exp, Exp — ► Exp 

expSalloc : 

Exp — * Exp 

in_name$exp : 

Exp , Nani — ► Exp 

in_range$exp : 

Exp, Rng — ► Exp 

in_type$exp : 

Exp, Nam — ► Exp 

name$exp : 

Nam — ► Exp 

not_in_Jiame$exp : 

Exp, Nam — ► Exp 

not_in_range$exp : 

Exp, Rng — > Exp 

not_in_type$exp : 

Exp, Nam — ► Exp 

nullSexp : 

— ► Exp 

integer$exp : 

integer — ► Exp 

realSexp : 

real — ► Exp 

char$exp : 

integer — ► Exp 

or_else$exp : 

Exp, Exp — ► Exp 

parenSexp : 

Exp — ► Exp 

qual$ aggregate : 

Nam, Agg — ► Exp 

qualSexp : 

Nam , Exp — ► Exp 

typeSalloc : 

Sid — ► Exp 

typeSconversion : 

Nam, Exp — ► Exp 

Modes ( Mde ) 

inSmode : 

— Mde 

in_out$mode : — ► Mde 

noSmode : 

— *■ Mde 

outSmode ; 

— Mde 

Names (Nam) 

access$attr : 

Nam — ► Nam 

delta$attr : 

Nam — ► Nam 

digits$att.r : 

Nam — ► Nam 

derefSname : 

Nam — ► Nam 

directSname : 

Id — ► Nam 

funcScall : 

Nam, Pss* — + Nam 

Id$attr : 

Nam, Id — ► Nam 

indexedScomp : 

Nam, Exp* — ► Nam 

name_type$conversion 

Nam, Nam — ► Nam 

param$attr : 

Nam , Id, Exp — ► Nam 

selected$comp : 

Nam, Id — ► Nam 

sliceSop : 

Nam, Rng — ► Nam 
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B.1.20 Parameter Specifications (Pms) 

accessSparam : Id, Nam — ► Pms 

access -default Spar am : Id , Nam, Exp — ► Pms 

defaultSparam : Zd, Mde, Nam , Exp — + Pms 

normalSparam : Zd, Mde, Nam — ► Pms 

B.1.21 Pragmas ( Prg ) 

% 

paramSpragma : Zd, Pss — ► Prg 

simpleSpragma : Id — +• Prg 

B.1.22 Parameter Associations (Pss) 

named_exp$arg : Zd, Exp — ► Pss 

named_name$arg : Zd, Nam — » Pss 

B.1.23 Record Component Associations (Pea) 

choiceSassoc : Cci, Exp — ► Rea 

B.1.24 Ranges (Png) 

attrSrange : Nam — ► Rng 

explicitSrange ; Exp, Exp — ► Rng 

parm_attr$range : Nam, Exp — ► Rng 

B.1.25 Subtype Indications (Sid) 

constrainedSsubtype : Nam, Cns — ► Sid 

namedSsubtype : Nam — ► Sid 

subtype$range : Rng — + Sid 

B.1.26 Subprogram Specifications ( Sps ) 

function$spec : Zd, Pms , Nam— ► Sps 

procedure$spec : Zd, Pms*— * Sps 

B.1.27 Statements ( Stm ) 

stmSlst : list(Stm) — ► Stm 

agg_code$stm : Nam, Agg — ► Stm 

assignSstm : Nam, Exp — ► Stm 

call$stm : Nam, Pss* — ► Stm 

caseSstm : Exp, Ait — ► Stm 

cond$exit : Cnd — ► Stm 

declare$block : Dei, Stm — + Stm 

exp_xode$stm : Nam, Exp — + Stm 

forSloop : Zd, Rng, Stm — ► Stm 

func_return$stm : Exp — ► Stm 
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goto$stm : 
if$stm : 
ifLelseSstm : 
labledSstm ; 
nameSexit : 
name_cond$exit : 
namedSblock : 
namedSloop : 
named_declare$block : 
named_for$loop : 

named_reverse$loop : 
named_while$loop : 
nullSstm : 
plainSexit : 
plainSloop : 
raiseSstm : 
reraiseSstm : 
returnSstm : 
reverseSloop : 
simpleSblock : 
whileSloop : 
handledSstatement : 
unhandled$statement : 


Nam — ► Stm 

Cnd , Stm, Eif — ► Stm 

Cnd , Stm, Eif } Stm — ► Stm 

Id , Stm — ► Stm 

Nam — ► Stm 

Nam, Cnd — * Stm 

Id , Stm — ► Stm 

Id, Stm — ► Stm 

Id, Del , Stm — ► Stm 

Id, Id , Rng, Stm -+ Stm 

Jd, Id, Rng, Stm — ► Stm 
Id , Cnd, Stm — ► Stm 
— ► Stm 
— ► Stm 
Stm — ► Stm 
Nam — ► Stm 
— ► Stm 
— ► Stm 

Id, Rng , Stm — ► Stm 
Stm — ► Stm 
Cnd, Stm — ► Stm 
Stm, Xhd* — ► Stm 
Stm — + Stm 


B.1.28 Type Definitions (Tdf) 


accessStype : 
aliased_array$type : 
aliased_uc_array$t,ype : 
alLaccessStype : 
array$type : 
const_access$type : 

const_dec_fixed$type : 
const„float$type : 
dec_fixed$type : 
derStype : 
enum$type : 
extStype : 
float.$type : 
func$type : 
intStype : 

modStype : I 

namedStype : S 

ord JxedStype : I 

procStype : I 

recordStype : ( 

t_record$type : ( 

uc_array$type : T 


Sid -► Tdf 
Rng*, Sid — Tdf 
: Nam*, Sid — Tdf 

Sid — Tdf 
Rng*, Sid — Tdf 
Sid — Tdf 

Exp , Exp, Cns — ► Tdf 
Exp, Cns — ► Tdf 
Exp, Exp —►Tdf 
Sid — Tdf 
Id* — Tdf 
Sid, red — ► Tdf 
Exp — Tdf 
Pins*, Nam— ► Tdf 
Exp, Exp — Tdf 

Exp — Tdf 
Sid — Tdf 
Exp, Rng — * Tdf 
Pms*— ► Tdf 
Cmp*, Vrp— ► Tdf 
Cmp*, Vfp— ► Tdf 
Nam*, Sid — ► Tdf 
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B.1.29 Variants ( Vnt ) 

^ % 

variantSclause : Dch , Cmp , Vrp — ► Vnt 

B.1.30 Variant Parts (Vrp) 

no$ variant : Vrp 

* 

variants part : JVam, Vnt — ► Vrp 

B.1.31 Exception Choices ( Xhd ) 

choiceShandler : Id, Ech*, Stm —* Xhd 

exptShandler : Ech*, Stm —* Xhd 

B.2 Lexical Elements 

prgama 

pragma identifier [ ( pragma_argument_association { , pragma_argument_association} ) ] ; 

paramSpragma : Id, Pss* — ► Prg 

simpleSpragma : pragma, Id — ► Prg 

pragma-argument_association ::= 

[ identifier => ] name 
| [ identifier = > ] expression 

named„exp$arg : Id, Exp — ► Pss 

named_name$arg : Id, Nam — ► Pss 

B.3 Declarations and Types 

B.3.1 Declarations 

basic_declaration = 

type-declaration 
| subtype-declaration 
| object-declaration 
| number-declaration 
| subprogram-declaration 
| abstract_subprogram_declaration 
| package-declaration 
| renaming-declaration 
| exception-declaration 
| generic-declaration 
| generic-instantiation 

It is convenient to treat sequences of declarations as a single declaration. 
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DcJ$ 1st : Del* -* Del 


definingJdentifier 

identifier 


B.3.2 Types and Subtypes 

B.3.2.1 Type Declarations 

type-declaration ::= 

full_type_declaration 
| incomplete_type_declaration 
| private_type_declaration 
| private_extension_declaration 

full_type_declaration 

type definingJdentifier [ known-discriminant_part ] is type-definition 
| task_type_declaration 
| protected-type_declaration 


d_type$decl : 

Id, Dcp , Tdf — ► Del 

typeSdecl : 

Id, Tdf — Del 


type-definition ::= 

enumeration_type_definition 
| integer_type-definition 
| real_type_definition 
| array-type-definition 
| record_type_definition 
| access_type-definition 
| derived-type_definition 


B.3.2. 2 Subtype Declarations 
subtype-declaration 

subtype definingJdentifier is subtypeJndication ; 


subtype$decl : Id, Sid — ► Del 


subtypeJndication ::= 

subtype-mark [ constraint ] 


subtype_mark = 
name 
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constrainedSsubtype : 

Nam, Cns — ► Sid 

namedSsubtype : 

Nam — ► Sid 

subtype$range : 

Rng — ► Sid 


The form subtype$range applies only to discrete subtype definitions. 

constraint = 

scalar-constraint 
| composite-constraint 


scalar— constraint = 

range-constraint 
| digits-constraint 
| delta-constraint 


composite-constraint 

index-constraint 
| discriminant-constraint 


B.3.2.3 Classification of Operations 
B.3.3 Objects and Named Numbers 
B. 3.3.1 Object Declarations 
object-declaration ::= 

defining— identifier-list : [ aliased ] [ constant ] subtype— indication [ := expression ] , 

| definingJdentifierJist : [ aliased ] [ constant ] array_type_definition [ := expression ] ; 
| single_task_declaration 
j single— protected— declaration 


a_ C—i— objSdecl : 

Id, Sid, Exp —> Del 

a^c_obj$decl : 

Id, Sid — Del 

a_i_obj$decl : 

Id, Sid , Exp — * Del 

a„obj$decl : 

Id, Sid — Del 

cJ_obj$decl : 

Id, Sid, Exp —> Del 

c_obj$decl : 

Id, Sid -» Del 

i_obj$decl : 

Id, Sid, Exp — ► Del 

objSdecl : 

Id, Sid — Del 


All forms of object declarations are normalized such that each declaration defines exactly one 
name. This is always possible by [3.3.1]. 

definingJdentifierJist ::= 

defining -identifier { , defining—identifier } 
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B.3.3.2 Number Declarations 
number_declaration = 

defining_identifier_list : constant := expression 


real_const$decl : Id , Exp — ► Del 

int_const$decl ; Id, Exp — ► Dei 

Number declarations are disambiguated by static analysis into real and integer number declara- 
tions. 

B.3,4 Derived Types and Classes 

derived_type__definition 

[ abstract ] new subtype_indication [ record_extension_part ] 


derStype : 

Sid — Tdf 

extStype : 

Sid, red -» Tdf 


B.3.4.1 Derivation Classes 

B.3.5 Scalar Types 

range_constraint 

range range 


rangeSconstr : Rng — ► Cns 


range 

range_attribute_reference 
| simple_expression .. simp!e_expression 


attrSrange : 
explicit$range : 
parm_attr$range : 


Nam — + Rng 
Exp, Exp — ► Rng 
Nam, Exp —* Rng 


B.3.5.1 Enumeration Types 
enumeration_type_definition ::= 

( enumeration Jiteral_specification { , enumeration JiteraLspecification } ) 


enumStype : Jd* — ► Tdf 


enumeration _literal_specification — 

defi n ing identifier 

| defining_character Jiteral 
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defining_character_literal :: = 
character Jiteral 


char$enum : char — + Id 

id$enum ; Id — *• Id 

B.3.5.2 Character Types 

B.3.5.3 Boolean Types 

B.3.5.4 Integer Types 

integer_type_definition — 

signed _integer_type_definition 
| modular_type_definition 


signed_integer_type_definition ::= 

range si mple„expression .. simple_expression 


int$type : Exp, Exp — ► Tdf 


modular_type_definition = 
mod expression 


modStype : Exp — ► Tdf 


B.3.5.5 Operations of Discrete Types 

B.3.5.6 Real Types 

real_type_definition :: = 

floating_point_definition 
| fixed_point_definition 


B.3.5.T Floating Point Types 

floating_point_definition :: = 

digits expression [ reaLrange-specification ] 


float$type : 

Exp — ► Tdf 

const_float$type : 

Exp , Cns — ► Tdf 


real_range_specification ::= 

range si mple_expression .. simple_expression 


See scalar types (3.5). 
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B.3.5.8 Operations of Floating Point Types 

B.3.5.9 Fixed Point Types 

fixed_point_definition :: = 

ordinary_fixed_point_definition 
| decimal_fixed_pointq_definition 


ordinary _fixed_point_definition : := 

delta expression real_range_specification 


ord_fixed$type : Exp, Rng — ► Tdf 


decimaLfixed_point_definition 

delta expression digits expression [ reaLrange_specification ] 


const_dec_fixed$type : Exp, Exp, Cns — ► Tdf 

dec_fixed$type : Exp, Exp — ► Tdf 


decimal_digits_constraint ::= 

digits expression [ range_constraint ] 


constr__digits$constr : 

Exp, Cns — > Cns 

digits$constr : 

Exp — ► Cns 


B.3.5.10 Operations of Fixed Point Types 

B.3.6 Array Types 

array_type_definition :: = 

unconstrained_array_definition 
| constrained_array_definition 


unconstrained_array_definition = 

array ( index_subtype_definition { , index_subtype_definition } ) of component_definition 


aliased_uc_array$type : Nam * , Sid — ► Tdf 

uc_array$type : Nam , Sid — ► Tdf 

index_subtype_definition = 

subtype_mark range <> 


constrained_array_definition 

array ( discrete^subtype_definition { , discrete_subtype_definition } ) of component_definition 
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aliased_array$type : 
array$type : 


Rng*, Sid -> Tdf 
Rng*, Sid — Tdf 


discrete_subtype-definition :: = 
su bty p e_i n d ica tion 
I range 


Discrete subtype definitions are subsumed under subtype indications (Sic/). 

component-definition = 

[ aliased ] subtype-indication 


B.3.6.1 Index Constraints and Discrete Ranges 

index-constraint = 

( discrete-range { , discrete-range } ) 


index$constr : Rng * — > Cns 

discrete-range ::= 

subtype_indication 
| range 


B.3.6.2 Operations of Array Types 
B.3.6.3 String Types 
B.3.7 Discriminants 

discriminant-part 

unknown_discriminant_part 
| known-discriminant_part 


unknown_discriminant_part = 

(<>) 


known_discriminant-part = 

( discriminant-specification { ; discriminant-specification } ) 


box$discr : Dcp 

listSdiscr : Dcs — ► Dcp 


discriminant-specification = 

defining-identifierJist : subtype_mark [ := default-expression ] 

| defining-identifierJist : access-definition [ := default-expression ] 
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default-expression 

expression 


accSdiscr : 

Id, Nam — ► Dcs 

acc-init$discr : 

Id , Nam, Exp — ► Dcs 

init$discr : 

Id, Nam, Exp — ► Dcs 

simpieSdiscr : 

Id, Nam — ► Dcs 


B.3.7.1 Discriminant Constraints 
discriminant-constraint :: = 

( discriminant-association { , discriminant-association } ) 


discrSconstr : 


Dc a* 


Cns 


discriminant-association 

[ selector— name { | selector— name } => ] expression 


named $ assoc : Id , Exp — ► Dca 

B.3.7.2 Operations of Discriminated Types 

B.3.8 Record Types 

record_type_definition = 

[ [ abstract ] tagged ] [ limited ] record-definition 


record$type : Cmp* , Vrp — ► Tdf 

t_record$type : Cmp*, Vrp— ► Tdf 

record-definition :: = 
record 

component-list 
end record 
| null record 


component-list :: = 

component-declaration { component-declaration } 
| { component-declaration } variant_part 

j null : 


component-declaration ::= 

d efi ni ng— identifier — list : component-definition [ := default— expression ] ; 
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aliased_comp$decl : Id, Sid — ► Cmp 

compSdecl : Id, Sid — ► Cmp 

init_aliased_comp$decl : Id, Sid , Exp — * Cmp 

init_comp$decl : Id, Sid , Exp —*> Cmp 


Component declarations with multiple identifiers are replaced by multiple component declara 
tions. 

B.3.8.1 Variant Parts and Discrete Choices 

variant-part ::= 

case direct-name is 
variant 
{ variant } 
end case ; 


noSvariant: Vrp 

variant$part : Nam, Vnt* — + Vrp 


variant = 

when discrete_choice_list => 
component Jist 


variant$clause : Dch* , Cmp , Vrp — ► Vnt 


discrete_choice_list 

discrete_choice { 
| discrete_choice } 


discrete-choice :: = 
expression 
| discrete-range 
| others 


discr_other$choice : 

— Dch 

Exp$choice : 

Exp — > Dch 

rangeSchoice : 

Rng — ► Dch 


B.3.9 Tagged Types and Type Extensions 

B. 3.9.1 Type Extensions 

record-extension _part ::= 

with record-definition 
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B.3.9.2 Dispatching Operations of Tagged Types 
B.3.9.3 Abstract Types and Subprograms 
B.3.10 Access Types 

access_type_definition = 

access_to_object_definition 
j access_to_subprogram_definition 


access_to_object_definition ::= 

access [ generaLaccess_modifier ] subtype-indication 


generaLaccess_modifier 

all 

| constant 


access$type : 

Sid — Tdf 

all_access$type : 

Sid — Tdf 

const_access$type : 

Sid — Tdf 


access_to_jsubprogram_definition 

access [ protected ] procedure parameter-profile 
access [ protected ] function parameter_and_result_profile 


func$type : Pins*, Nam— ♦ Tdf 
procStype : Pms* — ► Tdf 


access-definition ::= 

access subtype_mark 


B.3.10. 1 Incomplete Type Declarations 

incomplete-type_declaration :: = 

type definingJdentifier [ discriminant_part ] ; 


d_i_type$decl : 

Id , Dcp — ► Del 

LtypeSdecl : 

Id — Del 


B. 3. 10.2 Operations of Access Types 

B.3.11 Declarative Parts 

declarative-part = 

{ declarative-item} 
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declarative-item 

basic_declarativeJtem 
| body 

basic_declarative_item :: = 
basic-declaration 
| representation-clause 
| use_c!ause 


body :: = 

proper-body 
| body^stub 


proper-body :: = 

subprogram-body 
| package-body 
| task-body 
| protected_body 


B. 3. 11.1 Completions of Declarations 

B.4 Names and Expressions 

B.4.1 Names 

name ::= 

direct-name 
| explicit-dereference 
| indexed-component 
| slice 

j selected-component 
j attribute-reference 
) type-conversion 
| function-call 
character-literal 


String and character literals that denote operators are included as direct names. String literals 
that denote string values are represented as aggregates. 

char $ Exp : integer — ► Exp 


direct-name ::= 
identifier 

| operator-symbol 


direct$name : Id — ► Nam 


120 




Names that are represented as strings, character literals, and identifiers are all treated uniformly 
as elements of type Id 

prefix = 

name 

| implicit-dereference 


explicit-dereference :: = 
name . all 


derefSname : Nam — ► Nam 


The abstract syntax for dereferencing includes explicit as well as implicit dereferencing. 


implicit-dereference 

name 


B.4.1.1 Indexed Components 

indexed_component = 

prefix ( expression { , expression } ) 


indexedScornp : Nam, Exp * — ► Nam 

B.4.1.2 Slices 
slice = 

prefix ( discrete-range ) 


slice$op : Nam, Rng — ► Nam 


B.4.1.3 Selected Components 

selected-component ::= 

prefix . selector-name 


selected$comp : Nam, Id — ► Nam 


Static semantics separates expanded names from selected components. 

selector_name = 
identifier 

| character-literal 
| operator-symbol 
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B.4.1.4 Attributes 

attribute-reference :: = 

prefix ' attribute-designator 


attribute-designator :: = 

identifier [ ( expression ) ] 
| access 
j delta 
| digits 


range— attribute-reference = 

prefix ' range_attribute-designator 


range_attribute_designator — 
range [ ( expression ) ] 


IdSattr : 

Nam> Id — ► Nam 

param$attr : 

Nam, Id } Exp — ► Nam 


There is special abstract syntax needed for attributes that are reserved words. 

B.4.2 Literals 
B.4.3 Aggregates 

aggregate 

record-aggregate 
| extension-aggregate 
| array-aggregate 


B.4.3.1 Record Aggregates 

record-aggregate ::= 

( record_component_association-list ) 


record-component-associationJist = 

record_component_association { , record-component-association} 
| null record 


nulLrecordSAgg : — ► Agg 

record$Agg : Rea* Agg 


record_component_association :: = 

[ component_choice_list => ] expression 
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choiceSassoc : Cd, Exp — ► Rea 


Positional parameter associations have been eliminated by static analysis and are represented 
with an explicit choice list. This normalization is possible since, by [4.3.1], discriminant values that 
determine variants are required to be static. 

component-choice Jist :: = 

selector-name { | selector_name } 

| others 


listSchoice : Id* — ► Cel 

othersSchoice : — ♦ Cel 


B.4.3.2 Extension Aggregates 
extension-aggregate = 

( expression with record_component_associationJist ) 


ext$Agg : Exp , Rea* — ► Agg 

null_ext$Agg ; Exp — ► Agg 


B.4.3.3 Array Aggregates 

array-aggregate = 

positional_array_aggregate 
| named-array_aggregate 

positionaLarray_aggregate = 

( expression , expression { , expression} ) 

| ( expression { , expression} , others => expression ) 

named-array_aggregate ::= 

( array_component_association { , array_component-association} ) 


named_array$Agg : 

Aca* -f Agg 

other_array$Agg : 

Exp*, Exp —> Agg 

pos_arr ay $ Agg : 

Exp* — Agg 

>n ::= 


= > expression 


array_comp$ assoc : 

Dch *, Exp —+ Aca 
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B.4.4 Expressions 

expression ::= 

relation { and relation } 

| relation { and then relation } 
| relation { or relation } 

| relation { or else relation } 

| relation { xor relation } 


and-then$ Exp : Exp , Exp — ► Exp 

or_els e$Exp : Exp , Exp — ► Exp 

Short-circuit operators are non-strict and require explicit representation, 
relation = 

simple_expression [ relational-operator simple_expression ] 

| simple-expression [ not ] in range 
| simple_expression [ not ] in subtype_mark 


in_name$ Exp : 

Exp , Nam 

— ► Exp 

in_range$ Exp : 

Exp, Rng — ► Exp 

in_type$ Exp : 

Exp, Nam 

— + Exp 

not-in-name$Exp : 

Exp, Nam 

— ► Exp 

not_in_range$Exp : 

Exp, Rng 

Exp 

not-in-typ e$Exp : 

Exp , Nam 

— ► Exp 


Static semantics distinguishes between membership tests where the name denotes an object and 
those where the name denotes a subtype. 

simple_expression 

[ unary-adding_operator ] term { binary_adding_operator term } 


term — 

factor { multiplying-operator factor } 


factor 

primary [ ** primary ] 
| abs primary 
| not primary 


primary 

numeric-literal 
| null 

| stringJiteral 
| aggregate 
| name 

| qualified-expression 
| allocator 
| ( expression ) 
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parenSExp : 

Exp — ► Exp 

qualSaggregate : 

Nam, Agg — ► Exp 

name$ Exp : 

Nam -+ Exp 

nullSExp : 

— ► Exp 

integerSExp : 

integer — ► Exp 

real $ Exp : 

real — ► Exp 


All aggregates are assumed to be qualified by static analysis. String literals are represented 
as qualified aggregates. It may be necessary for static analysis to introduce new type names for 
aggregates of anonymous array types. 

Numeric literals are separated into integer and real literals. 

B.4.5 Operators and Expression Evaluation 

All strict operators on ordinary values are represented in the abstract syntax as function calls. 
As with other function calls, the function designators specify the unique overload that applies. 
Non-strict operators or operators that take subtypes as arguments (e.g., in) have an explicit repre- 
sentation given below. 

logical-operator ::= 
and 

I o r 

| xor 

relational-operator = 

i / = 
i < 
i <= 
i > 
i >= 

binary-adding_operator :: = 

+ 

I - 
i & 

unary_adding_operator :: = 

| + 

multiplying_operator :: = 

* 

I / 

| mod 
| rem 
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highest_precedence_operator ;: = 
** 

| abs 

I not 


B.4.5.1 Logical Operations and Short-Circuit Control Forms 

B.4.5.2 Relational Operators and Membership Tests 

B.4.5.3 Binary Adding Operators 

B.4.5.4 Multiplying Operators 

B.4.5.5 Highest Precedence Operators 

B.4.6 Type Conversions 

type_conversion 

subtype_mark ( expression ) 

| subtype-mark ( name ) 


typeSconversion : Nam, Exp — * Exp 

name_type$conversion ; Nam, Nam — ► Nam 


B.4.7 Qualified Expressions 

qualified-expression 

subtype_mark’ ( expression ) 

| subtype_mark ' aggregate 


qual$Exp : Nam, Exp —► Exp 


The abstract syntax for qualified aggregates is covered under aggregates. 


B.4.8 Allocators 

allocator = 

new subtype-indication 
| new qualified-expression 


Exp $ alloc : 

Exp — ► Exp 

typeSalloc : 

Sid — ► Exp 
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B.4.9 Static Expressions and Static Subtypes 

B.4.9.1 Statically Matching Constraints and Subtypes 

B.5 Statements 

B.5.1 Simple and Compound Statements — Sequences of Statements 

sequence_of__statements :: = 

statement { statement } 


Sequences of statements can be treated as single statements. 

Sim$ 1st : Sim* — ► Stm 


statement = 

{ label } simple_statement 
{ label } compound-statement 


labeld$stm : Id, Stm — + Stm 


simple-statement : : = 
null-statement 
| assignment-statement 
| exit-statement 
| goto_statement 
| procedure_call_statement 
| return-statement 
| entry_call-statement 
| requeue_statement 
| delay-statement 
| abort_statement 
| raise_statement 
| code-statement 


compound_^tatement = 
if_statement 
| case-statement 
| loop-statement 
| block-statement 
| accept_statement 
I select^statement 


null^statement = 

null ; 


nullSstm : — ► Stm 
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label 


<< statement-identifier >> 


statement-identifier = 
direct-name 


B.5.2 Assignment Statement 

assignment-statement 

name := expression 


assignSstm : Nam, Exp — ► Stm 


B.5.3 If Statements 

if-statement ::= 

if condition then 

sequence_of_statements 
{ elsif condition then 

sequence-of_statements} 
[ else 

sequence_of-statements ] 
end if ; 


if$stm : 

Cnd, Stm, Eif — ► Stm 

ifLelse$stm : 

Cnd, Stm, Eif \ Stm — ► Stm 

Ei/$lst : 

Eif — Eif 

elsifSclause : 

Cnd , Stm — ► Eif 


condition 

expression 


Exp$condition : Exp — ► Cnd 


B.5.4 Case Statements 

case-statement = 

case expression is 

case-statement-alternative 
{ case-statement_alternative } 
end case ; 


caseSstm : Exp } Alt — ► Stm 
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case_statement_alternative :: = 

when discrete_choice_list => 
sequence_of_statements 


AIt$ 1st : 

Alt* — Alt 

caseSAit : 

Dc.h*, Stm —*■ Alt 


B.5.5 Loop Statements 

loop_statement — 

[ statement-identifier : ] 

[ iteration-scheme ] loop 
sequence_of— statements 
end loop [ identifier ] ; 


iteration-scheme ::= 

while condition 

| for loop_parameter-specificat!on 


loop_parameter-specification : : = 

definingJdentifier in [ reverse ] discrete_subtype_definition 


named_for$!oop : 
named_reverse$loop : 
named_while$loop : 
namedSloop : 
for Sloop : 
reverse$loop : 
whileSloop : 
plainSloop 


Id, Id, Rng , Stm — ► Stm 
Id, Id, Rng, Stm — ► Stm 
Id, Cnd, Stm — > Stm 
Id, Stm Stm 
Id, Rng, Stm — > Stm 
Id, Rng, Stm — * Stm 
Cnd , Stm — ► Stm 
Stm — ♦ Stm 


B.5.6 Block Statements 

block_statement :: = 

[ statement-identifier : ] 

[ declare 

declarative-part ] 

begin 

hand led _sequence_of-statements 
end [ identifier ] ; 


simpleSblock : 

Stm — ► Stm 

declareSblock : 

Del, Stm — ► Stm 

namedSblock : 

Id, Stm — * Stm 

named-declare$block : 

Id, Del, Stm — Stm 
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B.5.7 Exit Statements 

exit_statement :: = 

exit [ name ] [ when condition ] ; 


nameSexit : 
name-Cond$exit : 
plain$exit : 
condSexit : 


Nam — ► Stm 
Nam, Cnd — ► Stm 
— ► Stm 
Cnd —+ Stm 


B.5.8 Goto Statements 

goto_statement 

goto name ; 


goto$stm : Nam — ► Stm 


B.6 Subprograms 

B.6.1 Subprogram Declarations 

subprogram-declaration ::= 

subprogram-specification ; 


subp$spec : Sps — ► Del 

abstract-subprogram_declaration 

subprogram-specification is abstract ; 


subpSspec : Sps — ► Del 

subprogram-specification = 

procedure defining_program_unit_name parameter-profile 
| function defining-designator parameter_and_result_profile 


function$spec : Id , Pms* i Nam— ► Sps 

procedure$spec : Id , Pms*— ► Sps 

designator ::= 

[ parent_unit_name . ] identifier 
| operator-symbol 

defining-designator ::= 

defining_program_unit_name 
| defining-operator-symbol 
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defming_program_unit_name : : = 

[ parent_unit_name . ] defining ^identifier 


operator_symbol = 
stringJiteral 


defining_operator_symbol ::= 
operator_symbol 


parameter_profile = 

[ formaLpart ] 


noSparams : — ► Psig 

paramSlist : Pms — ► Psig 


parameter_and_result_profile = 

[ formaLpart ] return subtype_mark 


formaLpart ; : = 

( parameter_specification { ; parameter_specification } ) 


parameter-specification — 

defining-identifier Jist : mode subtype_mark [ := default-expression ] 
| defining-identifier Jist : access-definition [ default-expression ] 


access$param : 

Id, Nam — > Pms 

access_defa.ult$param : 

Id , Nam , Exp — ► Pms 

defaultSparam : 

Id , Mde, Nam , Exp — ► Pms 

normalSparam : 

Id , Mde, Nam —> Pms 


mode :: = 

[ in ] 

| in out 
| out 


inSmode : 

— Mde 

in_out$mode : 

Mde 

noSmode : 

-► Mde 

outSmode : 

-> Mde 
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B.6.2 Formal Parameter Modes 
B.6.3 Subprogram Bodies 

subprogram_body = 

subprogram-specification is 
declarative-part 

begin 

handied-sequence_of_statements 
end [ designator ] ; 


subpSbody : Sps, Dei, Stm — * Del 


B.6.3.1 Conformance Rules 

B.6.3. 2 Inline Expansion of Subprograms 

B.6.4 Subprogram Calls 

procedure_call_statement :: = 
name 

| prefix actuaLparameter_part ; 


call$stm : JVam, Pss* — ► Sfcm 


function_cali 

name 

| prefix actuaLparameter_part 


func$call : Nam, Pss — ► Nam 


actual_parameter-part 

( parameter-association { , parameter-association } ) 

parameter-association = 

[ selector-name => ] explicit_actual_parameter 


explicit_actual_parameter :: = 
expression 
| name 


named_exp$arg : Id, Exp — ► Pss 

named-name$arg : Id, Nam — + Pss 
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B.6.4.1 Parameter Associations 

B.6.5 Return Statements 

return_statement :: = 

return [ expression ] ; 


func_return$stm : Exp — ► Stm 

returnSstm : — ► Stm 


B.6.6 Overloading of Operators 

B.7 Packages 

B-7.1 Package Specifications and Declarations 

package_declaration = 

package_specification ; 


package_specification 

package defining_program_unit_name is 
{basic-declarative Jtem} 

[ private 

{basic_declarative Jtem} ] 
end [ [ parent_unit_name . ] identifier ] 


B.7. 2 Package Bodies 

package_body — 

package body defining_program_unit_name is 
declarative^part 
[ begin 

handled_sequence_of_statements 
end [ [ parent_unit_name . ] identifier ] ; 


B.7.3 Private Type and Private Extensions 

private_type_declaration :: = 

type definingJdentifier [ discriminant_part ] is [ [ abstract ] tagged ] [ limited ] private 


private_extension_declaration = 

type definingJdentifier [ discriminant_part ] is 
[ abstract ] new subtypeJndication with private ; 


d_ext$decl : Id, Dcp, Sid — + Del 

extSdecl : Id , Sid —> Del 
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B. 7.3.1 Operations of Private Types and Private Extensions 
B.7.4 Deferred Constants 
B.7.5 Limited Types 

B.7.6 User-Defined Assignment and Finalization 

B. 7.6.1 Completion and Finalization 

B.8 Visibility Rules 

B.8.1 Declarative Region 
B.8.2 Scope of Declarations 
B.8.3 Visibility 
B.8.4 Use Clauses 

use— clause 

use_package-dause 
| use-type-clause 


use_package-dause 

use name { , name } ; 


use$clause : Nam* — ► Del 


use-type_clause ::= 

use type subtype_mark { , subtype_mark } ; 


use-type$ clause : 


Nam 


Del 


B.8. 5 Renaming Declarations 

renaming-declaration 

object_renaming-declaration 
| exception_renaming-declaration 
| package-renaming-declaration 
j subprogram— renaming-declaration 
| generic_renaming_declaration 


B.8. 5.1 Object Renaming Declarations 

object_renaming-declaration 

definingJdentifier : subtype_mark renames name ; 


object$renaming : W, Nam, Nam -+ Del 
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B.8.5.2 Exception Renaming Declarations 

exception_renaming_declaration 

defining_identifier : exception renames name ; 


exception$renaming : Id, Nam — ► Del 


B.8.5.3 Package Renaming Declarations 

package_renaming_declaration ::= 

package definirrg_program_unit_name renames name ; 


B.8.5.4 Subprogram Renaming Declarations 

subprogram_renaming_declaration 

subprogram_specification renames name ; 


subpSrenaming : Sps, Nam — ► Del 


B.8.5.5 Generic Renaming Declarations 

generic_renaming„declaration : : — 

generic package defining_program_unit_name renames name ; 

| generic procedure defining_program_unit__name renames name ; 

| generic function defining_program_unit_name renames name ; 

B.8.6 The Context of Overload Resolution 
B.9 Tasks and Synchronization 
B.9.1 Task Units and Task Objects 

task_type_declaration 

task type defining_identifier [ known_discriminant_part ] [ is task definition ] 


single_task_declaration :: = 

task definingjdentifier [ is task definition ] ; 


task_definition 

{ task_item } 

[ private 
{task_item} ] 
end [ identifier ] 
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task-item :: = 

entry -declaration 
| representation-clause 


task-body ::= 

task body defining-identifier is 

declarative-part 

begin 

handled- sequence-of_statements 
end [ identifier ] ; 


B.9.2 Task Execution - Task Activation 
B.9.3 Task Dependence - Termination of Tasks 
B.9.4 Protected Units and Protected Objects 

protected-type_declaration ::= 

protected type defining-identifier [ known_discriminant_part ] is protected-definition 


single_protected_declaration : : = 

protected defining-identifier is protected-definition ; 


protected-definition 

{ protected_operation_declaration } 
[ private 

{protected-element-declaration} ] 
end [ identifier ] 


protected_operation_declaration 
subprogram-declaration 
| entry-declaration 

protected_element_declaration : : = 

protected-operation_declaration 
| component-declaration 


protected_body = 

protected body defining-identifier is 

{protected_operation_item} 

end [ identifier ] ; 


protected_operation_item = 

subprogram-declaration 
| subprogram-body 
| entry-body 
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B.9.5 Intertask Communication 

entry-declaration = 

entry defining -identifier [ ( discrete_subtype_definition ) ] parameter-profile 


accept-statement :: = 

accept direct_name [ ( entry_index ) ] parameter-profile [ do 
handled_sequence_of-statements 
end [ identifier ] ] ; 


entry-index = 

expression 


entry_body ::= 

entry definingJdentifier entry_body-formaLpart entry_barrier is 

declarative-part 

begin 

handled_sequence_of_statements 
end [ identifier ] ; 


entry_body_formal_part :: = 

[ ( entryJndex-specification ) ]parameter_profile 


entry_barrier 

when condition 


entry_index_specification 

for definingJdentifier in discrete_subtype_definition 


entry-call_statement :: = 

name [ actual_parameter-part ] ; 


requeue_statement = 

requeue name [ with abort ] ; 


B.9.6 Delay Statements, Duration, and Time 

delay_jstatement :: = 

delay_until_statement 
| delay_relative_statement 


delay-untiLstatement = 

delay until expression ; 
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delay_relative_statement :: 
delay expression ; 


B.9.7 Select Statements 

select-statement 

selective_accept 
| timed_entry_call 
j conditional-entry _call 
| asynchronous— select 


B.9.8 Selective Accept 

selective_accept :: = 
select 

[ guard ] select-alternative 

[°r 

[ guard ] select-alternative ] 
[ else 

$equence_of_statements ] 
end select ; 


guard :: = 

when condition => 


select-alternative = 

accept_alternative 
| delay-alternative 
| terminate-alternative 


accept-alternative ::= 

accept-statement [ sequence-of_statements ] 


delay-alternative = 

delay-statement [ sequence-of_statements ] 


terminate-alternative 
terminate ; 


B.9.9 Timed Entry Calls 

timed-entry_call ::= 
select 

entry-calLalternative 
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or 


delay_alternative 
end select ; 


entry_call_alternative = 

entry_call^statement [ sequence_oLstatements ] 


B.9.10 Conditional Entry Calls 

conditional_entry_call :: = 
select 

entry_calLalternative 

else 

sequence_of_jstatements 
end select ; 


B.9.11 Asynchronous Transfer of Control 

asynchronous_select 

select 

triggering-alternative 
then abort 
abortable_part 
end select ; 


triggering-alternative ::= 

triggering_statement [ sequence_of_statements ] 


triggering— statement :: = 

entry _call_statement 
j delay-statement 


abortable_part :: = 

sequence_of_statements 


B.9.12 Abort of a Task - Abort of a Sequence of Statements 

abort_statement = 

abort name { , name} ; 
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B.9.13 Task and Entry Attributes 
B.9.14 Shared Variables 

B.9.15 Example of Tasking and Synchronization 

B.10 Program Structure and Compilation Issues 

B.10.1 Separate Compilation 

B. 10.1.1 Compilation Units - Library Units 

compilation 

{compilation_unit} 


compilation-unit 

context-clause library-item 
| context-clause subunit 


library-item ::= 

[ private ] library_unit_declaration 
| library-unitJbody 


library_unit-declaration :: = 

subprogram-declaration 
| package-declaration 
| generic-declaration 
| generic-instantiation 
| library _unit_renaming_declaration 


library-unit-renaming_declaration ::= 
package_renaming_declaration 
| generic_renaming_declaration 
| subprogram_renaming_declaration 

library_unit_body :: = 

subprogram-body 
| package-body 


parent-unit_name :: = 
name 


libSunit : 

Cit*> Del — ► emu 

private$unit : 

Cit*, Del —* emu 

subSunit : 

Cit + , JVam, Del — ► emu 


Renaming of library units is dealt with in static semantics. 
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B. 10. 1.2 Context Clauses - With Clauses 

context_clause :: = 

{ context_item} 


con t ext J tern ::= 

with_clause 
| use_c!ause 


with_clause = 

with name { , name } ; 


withScontext : Nam* — ► Cit 


B. 10. 1.3 Subunits of Compilation Units 
body_stub 

subprogram J)ody__stub 
| package_body_stub 
| task_body_-stub 
| protected JDody^stub 


subprogram J>ody_£tub = 

subprogram_specification is separate ; 


s^subpSspec : Sps —► Del 


package_body_stub 

package body definingJdentifier is separate ; 


task_body_stub = 

task body definingJdentifier is separate ; 


protected J)ody_stub ::= 

protected body definingJdentifier is separate ; 


subunit :; = 

separate ( parent_unit_name ) proper Jjody 
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B. 10. 1.4 
B. 10. 1.5 
B. 10. 1.6 


The Compilation Process 
Pragmas and Compilations 
Environment-Level Visibility Rules 

B.10.2 Program Execution 

B. 10.2.1 Elaboration Control 

B.ll Exceptions 

B.ll.l Exception Declarations 

exception-declaration ::= 

defining identifier — list : exception ; 


excpt$decl : Id — ► Del 

As with object declarations, only a single name is defined by each exception declaration. 

B.ll. 2 Exception Handlers 

handled_sequence_of_statements 

sequence_of_jstatements 

[ exception 
exception— handler 
{ exception-handler } ] 


handledSstatement : Stm, Xhd — > Stm 

unhandledSstatement : Stm — ► Stm 


exception— handler __ 

when [ choice_parameter_specification : ] exception -choice { | exception-choice J -> 

sequence— of— statements 


choice$handler : Id, Ech , Stm Xhd 

expt$handler : Ech*, Stm Xhd 


choice-parameter^specification ::= 
defining-identifier 


exception-choice :: = 
name 
| others 


namedSexcpt : Nam — ► Ech 
othersSexcpt : — ► Ech 
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B.11.3 Raise Statements 


raise_statement :: = 

raise [ name ] ; 


raiseSstm : Nam — *■ Stm 

reraise$stm : — ► Stm 


B.11.4 Exception Handling 
B.11.5 Suppressing Checks 
B.11.6 Exceptions and Optimization 

B.12 Generic Units 

B.12.1 Generic Declarations 

generic-declaration :: = 

generic-subprogram-declaration 
| generic-package_declaration 


generic-subprogram-declaration : 

generic-formaLpart subprogram-specification ; 


generic-package-declaration = 

generic_formal_part package-specification ; 


generic_formal-part :: = 

generic { generic_formaLparameter_declaration 
| use_ciause } 

generic_formal_parameter_declaration ::= 
formaLobject-declaration 
| formal_type_declaration 
| formaLsubprogram-declaration 
| formal_package_declaration 

B.12.2 Generic Bodies 

B.12.3 Generic Instantiation 

genericJnstantiation :: = 

package defining_program_unit_name is 
new name [ generic_actual_part ] ; 

| procedure defining-program_unit-name is 
new name [ generic_actual_part ] ; 
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| function defining-designator is 

new name [ generic_actual_part ] ; 


generic_actual_part 

( generic-association { , generic-association } ) 


generic-association = 

[ selector-name => ] explicit-generic_actual_parameter 


explicit-generic_actual_parameter : : = 
expression 
| name 

| subtype_mark 

B.12.4 Formal Objects 

formal— object— declaration 

defining— identifier— list : mode subtype_mark [ := default-expression ] ; 


init_formal$obj : Id* y Mde, Nam, Exp — ♦ Gpd 

formalSobj : Id , Mde, Nam — * Gpd 


B.12.5 Formal Types 

formaLtype-declaration ::= 

type defining— identifier [ discriminant-part ] is formal— type— definition ; 


formaLtype-definition 

formaLprivate_type_definition 
| formal_derived_type_definition 
| formaLdiscrete_type_ definition 
| formal_signed Jnteger-type_definition 
j forma Lmodular_type_definition 
| formaLfloating-point-definition 
j formaLordinary-fixed-point-definition 
| formal— decimal— fixed -point— definition 
| formal_array_type_definition 
| forma l_access_type_definition 


B. 12.5.1 Formal Private and Derived Types 

formal_private_type_definition ::= 

[ [ abstract ] tagged ] [ limited ] private 
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formal_derived_type_definition ::= 

[ abstract ] new subtype_mark [ with private ] 

B. 12.5.2 Formal Scalar Types 

formal_discrete_type_definition 

(<>) 


formaLsigned_integer_type-definition = 
range <> 


formal_modular_type_definition 
mod <> 


formaLfloating_point_definition ::= 
digits <> 


formal_ordinary_fixed_point_definition :: = 
delta <> 

formal_decimaLfixed_point-definition = 
digits <> delta <> 


B. 12.5.3 Formal Array Types 

formaLarray_type_definition = 
array_type-definition 


B. 12. 5.4 Formal Access Types 

formal_access-type_definition : := 
access-type_definition 


B.12.6 Formal Subprograms 

formal_subprogram_declaration :: = 

with subprogram_specification [ is subprogram_default ] 


subprogram-default 

default-name 

I <> 


default-name = 
name 
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B.12.7 Formal Packages 

formal_package_declaration = 

with package definingJdentifier is new npme formaLpackage-actuaLpart ; 


formaLpackage_actual_part = 

( <> ) 

[ [ generic_actual_part ] 

B.12.8 Example of a Generic Package 

B.13 Representation Clauses and Implementation-Dependent 
Features 

representation-clause 

attribute_definition_clause 
| enumeration-representation -clause 
| record_representation_clause 
| at-dause 


attribute_definition-dause = 

for direct-name ' attribute-designator use expression ; 
| for direct-name ’ attribute-designator use name ; 


enumeration-representation_clause : : = 

for direct_name use enumeration-aggregate ; 


enumeration-aggregate ::= 
array-aggregate 


record-representation_clause = 
for direct-name use 
record [ rnod_clause ] 
{component-clause} 
end record ; 


component-clause 

component_clause_component— name at position range first-bit last-bit ; 


component_clause_component-name ::= 
direct-name 

| direct_name ’ attribute-designator 


146 


position 

expression 


first-bit :: = 

simple-expression 


last-bit 

simple-expression 


code-statement :: = 

qualified-expression ; 


agg_code$stm : Nam, Agg — ► Stm 

exp-Code$stm ; Nam, Exp — ► Stm 


restriction = 

identifier 

| identifier => expression 


delta-constraint 

delta expression [ range-constraint ] 


constr_delta$constr : Exp , Cns — ► Cns 

delta$constr : Exp — + Cns 

at-dause — 

for directed_name use at expression ; 


mod-clause 

at mod expression ; 


B.14 Ada 9X Input-Output 


147 





Index 



65 




^ ciggy 

71 




^ ~ chc i 

76 




•“cfti 

76 




cmp 

, 66 




dch 

61-< 

63, 68, 79 

elf ) 

75, 

76 



^ exp » 

71- 

74 



nam 

, 68 

, 70, 

73, 

81 

psi > 

62 




rngy 

64 





62 




stm j 

, 75- 

-78, 

81, 

82 

^tdfy 

63, 

65, 

66 


^~vrn i 

66 




^ " attr 

, 83 




1“ 

, 67 





Nh-Nl , 83 
Rng-lst , 65 

...,65, 66, 69, 71, 74, 76, 77, 79, 81 
abnormalstSLte , 49, 51, 64, 69, 70, 74 
access-type, 58 
access- value, 54, 55 
access-val, 54, 68, 74 
actualized-binding-list, 60, 00 
actualized-complist , 61 
actualized-components , 61, 61, 71 
actualized-constraint, 60, 60, 60, 61 
actuaiized-partial_range, 60, 60 
actualized-range-list , 60, 00 
actualized-value, 00, 60 
actualized_variants, 07, 61 
actualize, 57, 61, 0J 
adom, 56, 57, 79 
alLaccess, 67 
ancestor , 55, 55, 56, 73 
append— components, 07 
array-aggregate, 77 
array-component , 50, 69 
array-slice, 50, 69 
array-type, 56, 59, 65, 69 
array_value, 55, 55, 56 


array-val, 50, 55, 56, 59, 69 
assign-ih, 62, 63, 75 
base-range, 55, 55, 56 
base, 83 

belongs-to , 55, 53, 56, 59, 69, 72, 77 
bind-actuals, 80, 80, 81 
choice-lst, 76, 77 
choice-range, 76, 77 
choice- value, 76, 77 
cl- value, 57, 57, 57 
class-type, 56 
compatible , 62, 68 
component-actions, 71, 77 
component-type , 57, 57, 70 
composite-value , 55 
constant-access, 67 
constrain, 69 

con vert_re turn_ value, 80, 82, 82 
covers-fn, 76 
covers, 57‘ 77, 77, 77 
default-valua_fn, 62, 63 
descendant, 55, 55 
descriptor-value, 56, 50, 57, 60 
discrete-range, 53 
discrete_rng, 53-56, 60 
discrete-value, 54 

discrete-val, 53, 54, 56, 60, 64, 70, 72, 76-78, 
83 

discriminant-constraint, 59, 60, 71 
discriminant-ref, 60 
discriminant_union, 67, 07, 67 
discriminant-value, 56, 56, 57 
discr , 56, 57, 67, 68, 71 
elementary- value, 5^, 55, 55 
enum-type , 55, 56, 58 
exception, 49, 69, 70, 74, 76, 80, 81 
exit, 49, 76-78, 80 
expression-list, 68, 68, 69 
fields, 57, 61, 66, 67 
finalize-fn, 75 
find-component , 71, 71, 71 
first, 83 


148 


form al, 79 
func-profile , 59, 67 
func-return , 49, 80-82 
give«_parameter, £2, 82 
hig/2_boiifid, 53, 83 
in-mode , 79, 82 
in-out-mode , 79, 82 
included-in, 53 , 53, 69 
incompiete_fcype, 68 
index-actions , 65, 65 
index^coiistrai/ifc, 59, 60, 65, 83 
index-Jist, 6$, 69 
index_pairin£, 5^, 54 
indices, 5^, 54, 55 

in direct-discrimin an t-constrain t , 60 

indirect_index_constraint, 60 

is_access_to_object_type, 58, 56 

is-access-to-^subprogram-type, 58, 56, 59, 59 

is_access_type, 57, 58, 56 

is_array_fcype, 58, 59, 59 

is-boolean-type , 58 

is_ by-copy- type, 59 , 59 

is_by_re/erence_type, 59, 59 

is_cbaracter_£ype, 58 

is-composite-type , 57, 56, 58, 56 

is-discrete-type , 58, 56, 58 

is_eiementary_type, 57, 57, 59 

is_enir/neration_type, 56, 58 

is_integer-type, 58, 56 

is_modu/ar_j'n£eger_fcype, 58, 56, 58 

is_protected_type, 58, 59, 59 

is-real-type , 58, 56 

is_record_£ype, 58, 59, 59 

isscalar-type , 57, 56, 58, 83 

is_sign ed_j n t eger- type, 58 

isstring-type, 59, 59 

is-tagged-type , 58, 59, 59, 73 

is-task-type, 59, 59 

last, 83 

length , 83 

iocation, 50, 62, 63, 70, 74 
loop-id , 77, 78 
7oop_view, 77, 78 
iovv_bound, 53, 83 
make-range, 53, 64, 83 
make-jstate, 49, 50 
modular-type , 55, 56, 58, 64 
new-object-fn , 52, 62, 63, 74 
new-object, 50, 51, 52, 63, 70 
newsubprogram, 51, 51, 79 
newsubtype , 51, 51, 61, 62, 68, 83 


new-type-fn, 66, 67 

new-type , 57, 51, 63-65, 67, 68 

normaLstate, 49, 64, 69, 74 

normal, 49, 51, 52, 69, 70, 74, 76-78, 80-82 

not-used , 63, 65, 66, 68 

nubLrange, 53 , 54, 5^, 54, 69 

object-view, 62, 63, 68-70, 74, 75, 83 

operator, 81 

out-mode , 79, 82 

P-constraint , 62 

P-discriminant-constraint , 60 

p_index_constraint, 60 

P-indirec t-discrimin an t-constrain t, 60 

p-indirect-index-constraint, 60 

P-range-constraint, 60 

p^subtype, 61 

P- value, 60 

parameter-action, 82, 82, 82, 82 
parameter-list, 81, 82, 82 
parameters, 79 
pick, 52, 52 
pool-access, 67 

prefixset-with-element, 54, 54 
proc-exit, 80, 80, 80, 80 
proc-profile , 59, 67 
proc_re£urn, 49, 80, 82 
range-constraints, 65, 65 
range-constraint, 56, 59, 60, 65, 69 
range-ofsubtype, 56, 56, 72, 83 
ranges-ofLsubtypes , 56, 56 
real-range, 53 
real-rng, 53, 54 
real-value, 54 
real-val, 54, 70 
record-component, 50, 70 
record-type, 57, 59, 66, 67, 71 
record-val, 50, 55, 57, 59, 70, 71, 73 
return-check, 80, 80, 81 
return-value, 81 
run, 52, 53 

satisfies, 59, 59, 60, 74 
scalar-value, 54, 54 , 54, 55 
select-component-type , 57, 57, 57 
set-of, 54, 56, 57 
signed-integer-type, 55, 56, 64 
slice-check, 69, 69, 69 

some, 57, 59, 61, 63, 64, 66, 67, 73, 79, 81, 82 
subprogram-body-fn , 53, 81 
subprogram-body, 53, 80, 80, 81, 81 
subprogram-view, 79-81 
subprogram, 79-81 


149 



subtype-value, 56, 57, 60, 60 
subtype-view , 61, 62, 65, 67, 68, 71-74, 79, 83 
subtype, 55, 56, 58, 60-62, 64-68, 71, 73, 74, 
83 

test-in, 72, 73, 73 
the-parameter, 82, 82 
the^store, 49-51 
the-variant, 57, 61 
then, 52 
thimlc, 79, 82 
type-cons train ts, 65 
type-jstruct, 55, 55, 56, 58, 59, 69-71 
ultimate-ancestor, 55, 55, 55 
unelaborated, 79, 81 
universaLjnteger_£n, 63, 83 
universal-integer-type , 56 
universal real—tn, 63 
valuesplit-fn, 75 
vaiues_J2L_range, 54, 54 
variant-values, 57, 57 
variant , 57, 66 
h content(-), 50 
^ atty 53 
— [ — • — ] , 50 

-[-^2-], 50 
— [— * *3 —]i 50 
1 ^4 -] > 50 
-[- 1 -]> 50 

-[- 1 — ] > 50 

_ o6 J[-], 50 
_ 5 ^[_], 50 
_ 5 ^[_], 50 
J yp [-], 50 
{), 68 
V - .], 51 
51 


150 



REPORT DOCUMENTATION PAGE 


Form Approved 
OMB No. 0704 0188 


Public reporting burden for this collection of information is estimated to average l hour per response, including the time for reviewing instructions, searching existing data sources, 
gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this 
collection of information, including suggestions for reducing this burden, to Washington Headquarters Services. Directorate for Information Operations and Reports, 12 IS Jefferson 
Oavis Highway, Suite 1204. Arlington. V A 22202-4302. and to the Office of Management and Budget. Paperwork Reduction Project (0704-0180) Washington DC 20S03 


1. AGENCY USE ONLY (Leave blank) I 2. REPORT DATE 


March 1995 


4. TITLE AND SUBTITLE 


3. REPORT TYPE AND OATES COVERED 

Contractor Report 


5. FUNDING NUMBERS 


Towards a Formal Semantics for Ada 9X 


6. AUTHOR(S) 


C NAS1-18972 


David Guaspari, John McHugh, Wolfgang Polak, and 
Mark Saaltink 


7. PERFORMING ORGANIZATION NAME(S) AND AOORESS(ES) 

Odyssey Research Associates 
301 Dates Drive 
Ithaca, NY 14850-1326 


9. SPONSORING /MONITORING AGENCY NAME(S) AND AOORESS(ES) 

National Aeronautics and Space Administration 
Langley Research Center 
Hampton, VA 23681-0001 


WU 505-64-10-56 


8. PERFORMING ORGANIZATION 
REPORT NUMBER 


ORA-TM-95-0044 


10. SPONSORING /MONITORING 
AGENCY REPORT NUMBER 


NASA CR-195037 


11. SUPPLEMENTARY NOTES 

Langley Technical Monitor: C. Michael Holloway 

Final Report - Task 11 


12a. DISTRIBUTION /AVAILABILITY STATEMENT 


12b. DISTRIBUTION CODE 


Unclassified - Unlimited 
Subject Category 62 


13. ABSTRACT (Maximum 200 words) 

The Ada 9X Language Precision Team was formed during the revisions of 
Ada 83, with the goal of analyzing the proposed design, identifying 
problems, and suggesting improvements, through the use of ma thematical 
models . 

This report defines a framework for formally describing Ada 9X, based 
on Kahn's "Natural Semantics", and applies the framework to portions of 
the language. The proposals for exceptions and optimization freedoms 
are also analyzed, using a different technique. 


14. SUBJECT TERMS 


Ada 95, formal semantics, natural semantics, optimizatic 


15. NUMBER OF PAGES 

157 


16. PRICE CODE 

A0 8 


17. SECURITY CLASSIFICATION 
OF REPORT 



19. SECURITY CLASSIFICATION I 20. LIMITATION OF ABSTRACT 
OF ABSTRACT I 


I Unclassified 
mcn 7S4n-ni-?RO-ssno 


Standard Form 798 (Rev 7-89) 













